Re: Parsing config files in a directory

On Sun, 25 Oct 2009, Robert Haas wrote:

> I especially don't believe that it will ever support SET PERSISTENT,
> which I believe to be a feature a lot of people want.

It actually makes it completely trivial to implement. SET PERSISTENT can
now write all the changes out to a new file in the include directory.
Just ship the database with a persistent.conf in there that looks like
this:

# Changes made with SET PERSISTENT will appear here.

We might want to put a warning about the risks of editing it by hand in
there too once those are defined. Then just dump anything the user asks
to be changed with that command at the end. So if I did:

SET PERSISTENT checkpoint_segments='3';

persistent.conf would now look like this:

# Changes made with SET PERSISTENT will appear here.
# user gsmith 2009-10-26 10:12:02 checkpoint_segments=16 (was 3)
checkpoint_segments=16

And since that will get parsed after the primary postgresql.conf in the
default configuration, this implemenation will completely bypass the issue
of how to parse and make changes to the master file. We only need to
support the subset we expect in persistent.conf, and you even have the
option of rejecting SET PERSISTENT if that file isn't in the standard
format when you execute that statement.

It also makes undoing ill-advised changes made with the command trivial;
just remove everything that was added to that file. Given the "glob
*.conf" implementation, you might just make a backup copy with a different
extension. Worst case you just note how many lines the file had when the
server last started successfully and comment out the ones after that.

That also makes it possible to do risky changes to the configuration (like
increases to shared_buffers) in a sane way, because of that easy
reversibility. If the server won't start after a SET PERSISTENT change,
there's only one file with a well defined format to back out changes to.
One of the problems with all previous suggestions here was not having a
good answer to the "what if you make a change that breaks the server from
starting?" issue.

As for your concerns about parsing comments, that's the first step on the
path to madness here. In my mind, one major accomplishment of Magnus's
patch is providing a way to push in config files changes of all sorts
without ever having to pay attention to the current postgresql.conf format
and its associated mess. The best we could do before this patch was
manually adding new, clean include files to the end of the existing
postgresql.conf, which is pretty obviously not a good solution either.
If the default file shipped includes a directory to glob from, the most
new tools (which includes SET PERSISTENT) should have to interact with the
primary postgresql.conf is just to confirm that include directive exists
before they create/update a simpler config file in the directory.

--
* Greg Smith gsmith(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD