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
stagnationin 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
underthere, 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@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com