Josh Berkus escribió:
> On 07/25/2013 02:02 PM, Tom Lane wrote:
> > Robert Haas <robertmhaas@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
withindirectory 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