Re: Configurable path to look up dynamic libraries - Mailing list pgsql-hackers

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 15 May 2001 16:12, Tom Lane wrote:
> teg@redhat.com (Trond Eivind Glomsrød) writes:
> >> The real bottom line here, though, is that you haven't shown me any
> >> positive reason to move the config files out of datadir.

> > It conflicts with the FHS -

> AFAIK, the FHS is not designed to support multiple instances of
> unprivileged daemons.

Really?  I've never read that into the FHS.

A '/etc/pgsql' directory can easily accomodate multiple config files, or a 
single config file with multiple sections.  It can just as easily have a 
whole tree of stuff under it.  And it can be owned by a non-privileged user. 
It just cannot be installed into without root's help -- and I know that that 
is the main objection here.

But I have a hard time understanding this all-or-nothing approach.  So what 
if we have a configure-time option to allow a more FHS-compliant approach?  
It won't interfere with the 'traditional' /usr/local/pgsql or /opt/pgsql or 
whatever way of doing things.  Further, it won't uglify the code in the least 
- -- it just allows more choice.  Further, it won't take a hacker long to make 
it work.  It won't even touch 'real' backend code, either -- this is a 
postmaster thingy. 

What's the opposition about?  We have all the configure options already for 
many things that the 'traditional' postgresql user cares nothing about.

But, on a more pragmatic note, I am contemplating the ability for the RPM's 
initscript to allow multiple postmasters -- even up to sane behavior in the 
presence of postmasters that it didn't start -- with multiple datadirs, etc. 

I don't want the RPM's to 'editorialize' any more than anyone else might -- 
but unless a more FHS-compliant approach is at least _allowed_ (NOT 
mandated!), I guess there will need to be some editorializing in the 
intscript as it will have to place its own config file somewhere in order to 
make multiple postmasters happen.

But I don't want to go through that if I don't have to -- or if it's going to 
happen anyway.

And, I know, currently the '-D' postmaster directive does, indirectly, point 
to the location of postgresql.conf..... :-) I will be using that in the 
initscript's logic if another option isn't done.

But, if I may editorialize a little myself, this is just indicative of a 
'Fortress PostgreSQL' attitude that is easy to get into.  'We've always done 
it this way' or  'This is the way PostgreSQL works' are pat answers to 
anything from 'Why can't I more smoothly upgrade?' to 'Why does PostgreSQL 
use non-SQL-standard case-folding?' to 'Why does everything go in 
/usr/local/pgsql?' to 'Do I _really_ have to do an ASCII dump of my 100GB 
database in order to go to the next major version?' to any number of other 
FAQ's.

Just because we've always done it one way does not that one way correct make.

We're one component of a system -- and the PostgreSQL Group has done such a 
good job of being platform agnostic that the platform and systems issues are 
almost second-class citizens.

Well, gotta get off the soap box now, and get to work producing some code, I 
guess. People are going to be expecting multiple postmaster support in the 
RPMset soon. :-)
- --
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE7AZ+15kGGI8vV9eERAu+MAJ9bk8mY8n1qIk8zKqWM1K188/530wCeJnwd
ZZDjAosFhRnTENBWJ+THju4=
=mPC9
-----END PGP SIGNATURE-----