Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])

On Friday, July 26, 2013 10:35 AM Alvaro Herrera wrote:
> Josh Berkus escribió:
> > On 07/25/2013 02:02 PM, Tom Lane wrote:
> > > Robert Haas <robertmhaas(at)gmail(dot)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).

Sure, I think we can split into 2 patches, but I doubt it will make it any
easier
to get this feature completed.
The contention point can delay the first patch (automatic parse of conf.d)
which can
lead to further delay of ALTER SYSTEM SET patch and that will eventually
lead to its death.

With Regards,
Amit Kapila.