Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])

On 7/18/13 4:02 PM, Alvaro Herrera wrote:

> I think we should just put the config directives of ALTER SYSTEM into a
> file, not dir, alongside postgresql.conf; I would suggest
> postgresql.auto.conf. This file is parsed automatically after
> postgresql.conf, without requiring an "include" directive in
> postgresql.conf.

It is possible to build ALTER SYSTEM SET this way. One of the goals of
the implementation style used here wasn't just to accomplish that narrow
feature though. We keep running into situations where a standard,
directory based configuration system would make things easier. Each
time that happens, someone comes up with another way to avoid doing it.
I think that approach contributes to stagnation in the terrible status
quo of PostgreSQL configuration management.

I thought this was a good spot to try and re-draw this line because I
don't want just one program that is able to create new configuration
entries easily. I want to see a whole universe of them. ALTER SYSTEM
SET, tuning helpers, replication helpers, logging helpers, vacuum
schedulers. All of them *could* just dump a simple file into a config
directory with code anyone can write. And having ALTER SYSTEM SET do
that provides a strong precedent for how it can be done. (I'd like to
see initdb do that instead of hacking the system postgresql.conf as if
sed-style edits were still the new hotness, but that's a future change)

My claim, and that's one informed by writing pgtune, is that by far the
hardest part of writing a configuration addition tool is parsing a
postgresql.conf file. The expectation right now is that all changes
must happen there. Creating a new snippet of configuration settings is
easy, but no tools know where to put one right now. Instead we just
keep coming up with single, hard-coded file names that people have to
know in order to manage their installations.

> This seems the simplest way; config tools such as Puppet know they
> always need to consider the postgresql.auto.conf file.

Like this idea. What administrators really want, whether they realize
it or not, is to point Puppet at a configuration directory. Then the
problem of "what are the config files in the new version of Postgres"
happens once more and then it's over. Exactly what the files in there
are named should be completely under control of the administrator.

We're never going to reach that unless we lead by example though. The
database's configuration pushes people toward using a small number of
files with magic names--postgresql.conf, recovery.conf, and now
postgresql.auto.conf in your proposal. Meanwhile, all sensible
UNIX-style projects with complicated configurations in text files has
moved toward a configuration directory full of them. Here are some
directories on the last RHEL6 system I was editing configuration on this
week:

/etc/httpd/conf.d/
/etc/munin/conf.d/
/etc/ld.so.conf.d/
/etc/munin/conf.d/
/etc/dovecot/conf.d/
/etc/yum/pluginconf.d/

Some of them didn't get the memo that the right standard name is conf.d
now, but they're the minority.

It's fine to have a postgresql.conf file that you *can* make all your
changes to, for people who want to stay in the old monolithic approach.
But if there were also a conf.d directory under there, many classes of
administrator would breath a sign of relief. With all the precedents
people may have already ran into, with the right naming can be made
discoverable and familiar to a lot of administrators.

Telling them instead that there's this new postgresql.auto.conf file
that suddenly they have to worry about--I'd say don't even bother if
that's how you want to do it. That's making the problem I've been
trying to simplify for five years now even worse.

> I think the whole business of parsing the file, and then verifying
> whether the auto file has been parsed, is nonsensical and should be
> removed from the patch.

That was just trying to keep people from screwing up their configuration
while they get used to things. That and some of the other sanity
checking is not necessary, it was just trying to make the transition to
the new configuration approach less error-prone. I don't think anyone
would disagree that the current patch is doing enough of that error
checking work that the error checking itself is the most likely thing to
break.

--
Greg Smith 2ndQuadrant US greg(at)2ndQuadrant(dot)com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com