Re: Why conf.d should be default, and auto.conf and recovery.conf should be in it - Mailing list pgsql-hackers

Stephen Frost wrote:
> * Alvaro Herrera (alvherre@2ndquadrant.com) wrote:
> > Peter Eisentraut wrote:
> > > In my mind, a conf.d directory is an extension of a single-file
> > > configuration, and so it should be handled that way.
> > 
> > +1 on this.  This means
> > 
> > 1. it is to be read automatically by the server without need for an
> >    "include_dir conf.d" option in the main postgresql.conf.
> 
> I am not thrilled with the idea that we're claiming ownership of the
> directory which postgresql.conf happens to reside in and you had better
> not have any 'conf.d' directory in there unless it's the one for PG.

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.

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.

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.

> > 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?

> > 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?

> > 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.

> > Taken together, these properties guarantee that it's an useful mechanism
> > to be used by system-level deployment/configuration tools such as Puppet
> > et al.
> 
> 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.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services