Josh Berkus escribió: > On 07/25/2013 02:02 PM, Tom Lane wrote: > > Robert Haas <robertmh...@gmail.com> writes: > > > >> My thought is that people might put postgresql.conf in a directory > >> that only contains configuration files and isn't writeable by the > >> postgres user. So I would expect to find postgresql.auto.conf in the > >> data directory always. > > > > Yeah, exactly. I think putting it anywhere but $PGDATA is a bad idea, > > and a sysadmin who thinks he knows better probably doesn't. > > Please see Greg Smith's fairly strong arguments for putting it in the > config/ directory.
As far as I see, there are two argument he makes: 1. We ought to have conf.d/ (not config/) so that tools have a way to deploy snippets (e.g. pgtune) 2. we ought to have all the config files together so that versioning tools (Puppet) can just say "keep all files within directory X versioned" and not have to care about specific file names, etc. I can buy (1), because that's a pretty common design for daemons nowadays. But I think that's its own patch, and there's no reason that this patch should be messing with this. I don't care all that much about (2), but I have no problem with doing that. So we could have two patches, first one that introduces a conf.d subdir that's automatically parsed after postgresql.conf, and another one that implements ALTER SYSTEM by using a file within conf.d. The reason I say we need a separate patch for conf.d is that I think it'd be easier to argue about it in isolation, than having it be entangled with ALTER SYSTEM stuff. The main contention point I see is where conf.d lives; the two options are in $PGDATA or together with postgresql.conf. Tom and Robert, above, say it should be in $PGDATA; but this goes against Debian packaging and the Linux FHS (or whatever that thing is called). -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
