Well, in this case, I've long been aware of the dump/reload cycle when
incrementing any major version, and had already setup PG 8.1 using the RPMs
from the PostgreSQL website, so for me, it was just a case of removing the PG
RPMs and then installing the CentOS RPMs.
Where this broke is that php-pgsql was looking for libpg.so.3, but PG 8.1
installs libpg.so.4, and AFAI can tell, this is now resolved.
-Ben
On Friday 30 December 2005 08:58, Lamar Owen wrote:
> On Thursday 29 December 2005 07:01, Johnny Hughes wrote:
> > > Is this PG 8.1 ever going to be part of the official 4.x release, or is
> > > this something that's done separately by you instead of coming from
>
> > No, it will never be in base / updates, it will be in centosplus (after
> > we move it out of testing).
>
> You need to warn people about updating with centosplus enabled, otherwise if
> they use centosplus (for perhaps the unsupported kernels or PHP5) and they
> have a running PostgreSQL instance, they will get a nasty surprise.
>
> To the OP, a major PostgreSQL version jump/upgrade is virtually impossible
to
> automate within the constraints of the RPM mechanism (and yum/up2date do not
> change the underlying mechanism, except perhaps the order in which triggers
> fire and scriptlets execute, but I've not tested that). You need to know to
> do a full backup/dump and wipe the database dir before the upgrade, then do
> your restore. Database upgrades are not easy; PostgreSQL, because of the
way
> and depth in which it can be extended can be more difficult than most, but
> that's due to its power.
> --
> Lamar Owen
> Director of Information Technology
> Pisgah Astronomical Research Institute
> 1 PARI Drive
> Rosman, NC 28772
> (828)862-5554
> www.pari.edu
> _______________________________________________
> CentOS mailing list
> CentOS@xxxxxxxxxx
> http://lists.centos.org/mailman/listinfo/centos
>
--
"The best way to predict the future is to invent it."
- XEROX PARC slogan, circa 1978
