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
