Re: Why conf.d should be default, and auto.conf and recovery.conf should be in it

Avlaro,

* Alvaro Herrera (alvherre@2ndquadrant.com) wrote:
> Please explain.  I don't see a reason not to.  Are you saying you expect
> to put, say, Apache configuration files in the same directory as
> PostgreSQL's?  That doesn't sound really tenable to me, and it doesn't
> sounds like what any sane admin would do.

That doesn't mean we get to dictate it.

> In /etc you have /etc/postfix/ where you have Postfix files, and
> /etc/exim4 where you have Exim files, and /etc/apache2 or whatever.  And
> if each of those software packages uses a "conf.d" or "conf-enabled"
> directory, they use a hardcoded name for a place inside their own
> subdirectory, not one directly in /etc.

I missed the part of this where you point out that Apache on Debian has
some kind of problem because it's possible for an admin to remove the
'IncludeDir sites-enabled' line from apache2.conf.

> What you don't have is /etc/exim4.conf and /etc/postfix.conf and
> /etc/apache.conf, where each of those files specifies that I would
> please like to have extra files loaded from /etc/exim.conf.d and
> /etc/apache.conf.d, and that packages please figure out by parsing my
> config file in whatever random format I have invented to figure out
> where snippets are to be stored.

Right, there's absolutely zero cases of /etc/*.conf files these days.
Nor are there any /etc/*.conf.d directories.

</sarcasm>

Sure, maybe we all feel that there should be an /etc/pam directory
instead of /etc/pam.conf and /etc/pam.d, but that doesn't make it so,
and we're only talking about a subset (perhaps a majority, but it's
certainly not a totality) of PG users- not everyone is using Debian or
RH or even *Linux* or GNU tools to run PG with.

> > > 2. it is to be placed alongside postgresql.conf, not necessarily in
> > >    PGDATA.
> >
> > I certainly agree with this idea- but I feel it should be configurable.
> > The path which is passed in should be relative to the location of
> > postgresql.conf.
>
> What would be the point of having it be configurable?

To allow admins to configure it?  Perhaps their policy is that it must
be postgresql.conf.d, or that they want it served off of an NFS mount
instead of being pulled from /etc, or maybe they only back up /srv but
they don't want to change where the package manager dumps the
postgresql.conf that's used for starting up the cluster?

> > > 4. there is no point in "disabling" it, and thus we offer no mechanism
> > >    to do that.
> >
> > No.  There should be a way to disable it.
>
> What's you rationale for this?

I don't want PG randomly guessing at directories to go poking around in
for config files.  It's also documentation.

> > > 5. its entries override what is set in postgresql.conf, and are in turn
> > >    overridden by what is set in postgresql.auto.conf.
> >
> > For my part, I'd rather my configurations be deterministic and would
> > prefer that we error on obvious misconfigurations where values are set
> > and then reset.
>
> Any convention we establish will make configurations deterministic.
> Random variations such as making the conf.d directory be configurable
> would make them non-deterministic.  ISTM you're contradicting yourself
> here.

Perhaps you see it that way, but I certainly don't.  Having conf.d be
configurable doesn't mean that we have one file with "work_mem = 1GB"
and another with "work_mem = 5GB" where it's not at all clear which one
is actually what gets used.

> > It will be a useful mechanism for puppet even with the ability to
> > disable it in postgresql.conf (you're probably managing that with puppet
> > also, or keeping it at the system default which will likely include the
> > include_dir option by default- but, yes, you'd need to check that) and
> > without the "override previous definition" option.
>
> Meh.  External packages (say, postgis) will be able to add their own
> files into conf.d without having to check what its actual location is,
> and without having to check whether the thing is enabled in the first
> place.  If we make it disable-able, packages will not be able to do
> that; or rather, they will be able to add files, but they will have no
> effect.

Which cluster directory is the packager of PostGIS going to put his
config snippets into, exactly?  Even if you force the hard-code conf.d
idea, the packager will still need to figure out what clusters exist.

Although, if you could make the conf.d directory configurable, and have
more than one, then we actually could have a "system-wide" directory and
then a per-cluster directory, which *would* make things easier for
packagers.  But, oh wait, don't forget that the "system-wide" one would
still need to be major-version-specific...
Thanks,
    Stephen