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