[CentOS] Postgresql 8

Mon Oct 17 15:13:52 UTC 2005
Lamar Owen <lowen at pari.edu>

On Monday 17 October 2005 09:25, James B. Byrne wrote:
> Does anyone here know of a repository that has PostgreSQL v.8 for
> CentOS-4? If so, where is it? 

No repository, but the canonical location for downloading PostgreSQL is from 
ftp.postgresql.org's mirrors.  Let's see:
ftp://ftp.us.postgresql.org/pub/mirrors/postgresql/binary/v8.0.4/linux/rpms/redhat/rhel-es-4/ 
has what you want, I believe.  No, it's not yummified.  Due to the upgrade 
issues referenced below, this is, IMO, a Good Thing.

> Are there caveats that I should know 
> about?

Yes, several.

PostgreSQL major version upgrades require a specific procedure to be followed, 
that, if you don't follow it exactly, might render your database unusable 
until you downgrade (it will never destroy data, but you just won't be able 
to get to it until to reinstall the older version).  Now, if you don't have 
any data stored on the existing version, you can upgrade to your heart's 
content (but you might have to rebuild some things from source RPM, like 
php's PostgreSQL support, due to a different client library version).

The upgrade procedure is fully documented in the main PostgreSQL 
documentation, but, in a nutshell:
Dump your old database while the old version is running (see the man page for 
pg_dumpall);
Save that dumpfile somewhere the RPM's don't touch (that is, move it out 
of /var/lib/pgsql)
Stop postmaster (service postgresql stop is standard; some Red Hat versions 
have used service rhdb or service rhpostgresql)
Blow away the contents of /var/lib/pgsql/data, saving a copy of 
postgresql.conf and pg_hba.conf first.
Upgrade the postgresql packages.
Start the postmaster with 'service postgresql start' as root.  This also 
initializes the database tree under /var/lib/pgsql; you don't have to 
separately initdb.  However, if I remember correctly, there are some odd 
SELinux issues; hmm... see 
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=152591
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=143208 and, for a 
high-level view: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=149237
(also read https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=159503 for 
some really interesting discussion and input from Tom Lane.  Tom is one of 
the core PostgreSQL hackers, to put it into perspective).

In a nutshell, setenforce 0 then start postmaster, then stop postmaster, then 
setenforce 1 again.

Now, back to the upgrade:
Once the database is initialized and postmaster is running, restore your dump 
from the earlier step (see the pg_restore manpage for options).

For most databases this should work; there are exceptions, particularly if 
you've developed custom server-side functions in C (they have to be 
recompiled and re-created with the new version).

As mentioned previously, you are putting in a new version of libpq.so; this 
breaks many things if you aren't prepared for it.  ANYTHING linked to the 
older libpq.so will fail dependencies, and will need to be rebuilt from 
source RPM and installed.  You will then have to do this everytime a security 
update is issued for that package.  This impacts things like php's pgsql 
support and perl's DBI postgresql support, for starters.  I think, but am not 
sure, that there is a workaround in the 8.0.x RPM's; since I passed the baton 
of maintainership to Devrim, I'm not as up on it as I used to be when I did 
all the packaging.
-- 
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC  28772
(828)862-5554
www.pari.edu