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@centos.org http://lists.centos.org/mailman/listinfo/centos