Josh,
* Josh Berkus (josh@agliodbs.com) wrote:
> In 9.3, we added support for a config directory (conf.d), but have it
> disabled by default. For tool authors, this makes conf.d useless since
> you never know, on any given installation, whether it will be
> present/enabled or not. While we don't want to prevent users from
> disabling it, conf.d only becomes useful if it's present by default.
> There's a simple reason why: if you want to write a tool which manages
> postgresql.conf, you don't want the user to have to manually edit
> postgresql.conf (and create a directory) in order to enable the tool.
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.
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. Indeed, the Debian package would at least be able to
indicate, through the existance or not of the directory, whether a given
cluster was set up by default with the conf.d structure or not.
> 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.
> 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.
> If conf.d does NOT exist by default, things become complicated, and
> backwards compatibility for replication management tools becomes much
> harder.
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.
> 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.
I disagree with enabling that by default.
Thanks,
Stephen