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 at centos.org > http://lists.centos.org/mailman/listinfo/centos > -- "The best way to predict the future is to invent it." - XEROX PARC slogan, circa 1978