On 1/15/14, 1:53 PM, Josh Berkus wrote:
> I'm particularly thinking about this in relation to the merger of
> recovery.conf and postgresql.conf. There are several tools already
> (RepMgr, OminPITR, HandyRep, pgPool, etc.) which manage recovery.conf
> separately from postgresql.conf. These tools will want to continue
> managing recovery.conf as a separate file, even if it's /included in
> postgresql.conf now.
That seems like a very general argument. We'd need to consider exactly
what these tools want to do, and how that affects the recovery.conf
merger. My personal proposal was to allow postgresql.conf to contain
recovery parameters, but read recovery.conf last anyway. That would
solve that problem.
> If conf.d exists by default, and is enabled in postgresql.conf by
> default, this is easy: the tool just drops a recovery.conf file into
> conf.d.
That would just give false hope, I think. My standard operating
procedure is to delete the default postgresql.conf and write a new one
from scratch (or have deployment tools do it). I don't want to
subscribe to a policy that the only endorsed way to maintain
postgresql.conf is to start with the default one and edit around carefully.
The only way you could achieve your goal is to read the configuration
directory automatically, but that would come with its own set of problems.
> Yes, I'm also arguing that postgresql.auto.conf should go into conf.d.
> I said I'd bring that up again after ALTER SYSTEM SET was committed, and
> here it is.
Independent of the above, I don't agree with that. postgresql.auto.conf
is a special thing and should have its own special place. For once
thing, when putting configuration files in a separate directory
structure (/etc/ vs /var), then postgresql.auto.conf should stay in the
data directory.