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

On 01/15/2014 11:10 AM, Stephen Frost wrote:
> I don't buy this argument one bit- certainly, on Debian, the defaults
> are overridden for a number of variables already and could be done to
> enable a conf.d directory as well.  Directory creation would, of
> course, also be able to be handled by the Debian package.  Any tool
> which is being packaged for Debian would simply have to Depend on the
> version of the PG package that enabled the conf.d option by default.

However, Debian is *never* going to add conf.d to the packages if we
don't recommend it as an upstream project.  And, frankly, I use the
apt.postgresql.org packages anyway, which would certainly include
anything which was decided on this list.

> This doesn't deal with upgrade cases or where the user has disabled the
> feature and so the tool would need to check for a directory's
> existance, but changing our default isn't going to completely address
> that issue either.  

There's a HUGE difference between "This tool depends on conf.d, so
please don't disable it" and "please edit postgresql.conf in the
following way, and create this directory with these permissions ..."

>> 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.
> 
> Certainly an interesting thought.

It's more than in interesting thought.  It's the difference between
having 20 lines of backwards compatibility code, and having 150 plus a
bunch of additional user documentation and setup.

>> 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.  Changing file locations and variable names is a fairly simple
>> exercise in backwards compatibility.
> 
> This isn't quite that simple on at least Debian, and I believe RH, as
> there's going to be multiple directories involved (one for each cluster
> which exists on the system).  Also, there are rules which packages need
> to follow on Debian regarding conf file changes, which these certainly
> would be.

Again, from the perspective of the tool (assuming it already supports
Debian), this is just a directory change.  ("if version == 9.4,
directory = directory + "/conf.d/")

> My recommendation would be to argue the point with the package
> maintainers.  Even if we *had* a default, I'm not convinced that the
> package maintainers would keep it that way until and unless they update
> their scripts and whatnot to handle it.

This is disengenuous.  The package maintainers are never, ever going to
add conf.d and enable it by default unless it's the official
recommendation of the PostgreSQL project that they do so.  Exactly how
far would I get with "I couldn't get pgsql-hackers to agree to this, so
I'm asking you"?

On 01/15/2014 11:40 AM, Peter Eisentraut wrote:
> 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.

Three issues:

a) if postgresql is still going to look for a recovery.conf file in the
usual place, but we are changing the names and meaning of some of the
parameters, then aren't we making the upgrade problem much worse?

b) what if the admin *does* want to disable reading recovery.conf in
order to prevent old utilities from mistakenly including one?  How will
they do that?

c) would this be in the configdir, datadir, or both?

I'd thought that part of the idea of the merger was to remove the
"magic" status of recovery.conf.

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

Frankly, I'm not concerned about people who rewrite their
postgresql.conf from scratch already; it's *easy* to tell those people
to re-add the conf.d reference to that file.  I'm talking about the vast
majority of our users who never edit pg.conf by hand.

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

Ah, I'd forgotten about that line of argument.  Where is auto.conf now?

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com