Re: Parsing config files in a directory - Mailing list pgsql-hackers

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@gregsmith.com http://www.gregsmith.com Baltimore, MD