[CentOS] PostgreSQL 8.1 on CentOS4

[Lamar Owen]

On Friday 18 November 2005 22:42, Jim Perrin wrote:
> > Oh, I forgot to mention one detail you will want to know about.  The
> > initscript will get overwritten the next time you upgrade the RPM (it is
> > not a configuration file, after all, but a program and part of the
> > package and subject to change from time to time).  Thus if your
> > postmaster quits responding when you upgrade next, you'll know why.

> Perfectly reasonable, but along these lines (at least for the
> rhel/centos/fedora rpms) why not seperate things out like what's done
> with bind, apache, nfs etc, and put any options like -i into an
> /etc/sysconfig/pgsql  file?

That's an excellent question, Jim, and with current packages might be an 
option.

However, in the future the PostgreSQL RPM's will gain the feature of allowing 
multiple databases of multiple versions to coexist; in this case one database 
in the cluster might need to listen on one address and one port, and another 
on another address:port pair, and another might need Unix sockets only.  
Apache is probably the only other package among those that has this sort of 
capability (similar to, yet different from, virtual hosting), but I envision 
the ability to run a 7.4.8 PostgreSQL backend in parallel with an 8.1 backend 
with Slony-I replicating from the old to the new for migration and migration 
testing.  That would be like running multiple websites on the box with 
multiple versions of apache.

Consistent with the PostgreSQL philosophy, the configuration data for the 
database itself belongs with the database's data (it is possible to store it 
elsewhere, but it is still database and not backend specific).

I could have, for instance, a database in /var/lib/pgsql/data (the default) 
listening on localhost:5432, a database in /var/lib/pgsql/finance listening 
on 192.168.1.12:6793, a database in /var/lib/pgsql/website listening on 
209.119.165.234:1520 (and running as a different user, in fact, with a 
different userbase, different set of postgres user passwords, etc).

This makes the obvious solution not so obvious; but, yes, it has been 
suggested before.  As postgresql.conf solves the problem in the general case 
in a manner consistent with all the non-Linux PostgreSQL installations (I 
guess you heard Sun's news today, right?), I decided to not do it 
the /etc/sysconfig/pgsql way.  Devrim, Tom, and I might decide to do it 
differently some day; past are the days I decided these things more or less 
unilaterally (thank goodness; I didn't always make the right choices!).

I hope that helped understand the mindset; sorry for the verbosity, I don't 
have time to make it shorter tonight.
-- 
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC  28772
(828)862-5554
www.pari.edu