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


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to