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:
> Stephen Frost wrote:
> > 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.
>
> I don't see that this is parallel. For one thing, I don't think you
> would normally have multiple apache2.conf files. In the other hand,
> even if you had more than one, surely the one that's managed by the
> packaging system, if there is one, is not going to want to have that
> line changed, because that would immediately break all modules installed
> by packages.

My point above was that having it configurable does *not* make it a
burden on packagers or tool authors. If it did, the Debian folks would
be complaining to ASF to have the option removed and instead required.
Indeed, the fact that it's configurable, in my view, is how we ended up
with sites-available and sites-enabled in the first place. Perhaps we'd
have gotten there without it, but it sure feels like having the option
was a help and not a hindrence.

> I just checked my system, and it seems to me that most cases that have
> .conf files and something.conf.d directly in /etc are more because of
> historical reasons than because they have made a conscious, contemporary
> decision to do that. Do we want to replicate choices made in the
> 1990's?

There are people who are still running OS's from the 1990's and forcing
what we feel is the 'right' answer on users is helping ourselves more
than helping our users, imv.

> Yeah, so instead of making a rational choice for people using all
> platforms, mirroring the rational choice made by Linux/Debian/GNU, lets
> make an irrational choice so that everybody will be constantly bitten by
> it, regardless of platform.

This argument that it only works if it's hard-coded simply doesn't fly
when you look at the existing examples in Debian.

> > To allow admins to configure it? Perhaps their policy is that it must
> > be postgresql.conf.d
>
> This example sounds rather weak. I mean, if they *must* have
> /etc/postgresql/9.2/main/postgresql.conf.d instead of
> /etc/postgresql/9.2/main/conf.d, why aren't they forced to have

You're being completely Debian-centric here. It's possible they've got
their own /etc directory structure which doesn't match your
expectations- and that's *fine* until we start forcing the issue on
them. Perhaps they prefer to have /etc/postgresql.conf and
/etc/postgresql.conf.d, why should we be preventing them from doing so
just because the OS's and distro's that we run don't work that way?

> > or that they want it served off of an NFS mount instead of being
> > pulled from /etc,
>
> So conf.d would be in an NFS mount but postgresql.conf would not?

That's correct- and it wouldn't be mounted at
/etc/postgresql/9.2/main/conf.d, and please don't start in with the
symlinks argument- *that* would be a mess.

> > I don't want PG randomly guessing at directories to go poking around in
> > for config files. It's also documentation.
>
> Documentation is fine. We can have a comment at the top of
> postgresql.conf saying "also see files in postgresql.conf.d/" or some
> such. I can hardly thing that opening and reading a subdirectory named
> conf.d or postgresql.conf.d, *in the same directory as postgresql.conf*
> is "randomly poking".

It's completely random when we have no idea where the postgesql.conf is
nor what other files or directories exist there today. Perhaps it's
100% true that, no where on this planet, a postgresql.conf file and a
conf.d directory/file/socket/whateve share a directory, but I wouldn't
bet on it. Hell, I'm half tempted to go make sure just to be sure to
prove anyone wrong who argues that case. ;)

Remember- these would not just be new installs, someone simply running
pg_upgrade to move to 9.4 would suddenly find their database server
trying to open a non-existant directory wherever their postgresql.conf
file resides.

Another issue is how does this scale up to directories for pg_hba.conf
or pg_ident.conf or friends- are we going to hard-code directories for
those too?

> If you want to argue that multiple lines setting the same variable
> should raise an error instead of "last definition wins", please do
> propose that separately.

I've brought it up a number of times before- having the lines be in
different files just makes it that much worse.

> > 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.
>
> This was a thinko on my part, I admit, which doesn't invalidate the rest
> of my argumentation. I think the way to think about this would be
> something like having mode in pg_ctlcluster (for example) that enables
> postgis for a certain cluster, which means it drops a certain file in
> the cluster's conf.d directory, as I described above.

Boy does that ever sound hokey.

> > 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...
>
> Hmm. I guess you could have /etc/postgresql/9.2/conf.d which is used
> for all clusters, yeah. The need for this is not as clear as a
> per-cluster conf.d though, and IMO would be a separate proposal.

Uh, ok, so now we're going to have an 'include_dir' option, but it can't
be used to change the default 'conf.d' and instead can only specify some
other directory to *also* check?

Thanks,

Stephen