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

* Alvaro Herrera (alvherre(at)2ndquadrant(dot)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.

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

> 3. it might or might not be writable by the running server; it's an
> operating-system-owned configuration location.

Works well enough, I suppose.

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

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

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

> I also think, but this is a secondary point, that initdb should write
> its modified settings into a file in conf.d instead of generating a
> custom postgresql.conf.

This makes sense.

Thanks,

Stephen