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

On Tue, 27 Oct 2009, Robert Haas wrote:

> I guess I didn't consider the possibility that someone might reuse an 
> 8.4 postgresql.conf on an 8.5 server.  That could be awkward.

Happens all the time, and it ends up causing problems like people still 
having settings for GUCs that doesn't even exist anymore.  You know how we 
could make this problem less likely to bite people?  By putting everything 
the user wants to customize that isn't done by initdb into another file. 
Then they can just move that file into the new version.  That's the 
direction we're trying to move here, except much slower than you're 
suggesting because we've already through about some of these gotchas. 
Obviously you could do the same thing by completely gutting the whole 
postgresql.conf, but I was hoping for a step in the right direction that 
doesn't require something that drastic yet.

The length of this thread has already proven why it's not worth even 
trying to completely trim the file down.  Had you never brought that up 
this discussion would be done already.  If you have a strong feeling about 
this, write a patch and submit it; I'm not going to talk about this 
anymore.

> I was thinking that the algorithm would be something like: "Read the old 
> postgresql.conf and write it back out to a new file line by line....

This sounds familiar...oh, that's right, this is almost the same algorithm 
pgtune uses.  And it sucks, and it's a pain to covert the tool into C 
because of it, and the fact that you have to write this sort of boring 
code before you can do a single line of productive work is one reason why 
we don't have more tools available; way too much painful grunt work to 
write.

> True, but actually having a good SET PERSISTENT command would solve
> most of this problem, because the tools could just use that.

The system running the tool and the one where the changes are being made 
are not the same.  The database isn't necessarily even up when the tool is 
being run yet.  The main overlap here is that one of the output formats 
available to future tools could be a series of SET PERSISTENT commands one 
could then run elsewhere, which is already on my pgtune roadmap when it's 
possible to implement.

You're doing a good job of reminding me why I didn't have a good vision of 
where this all needed to go until after I wrote a working tuning tool, to 
get a feel for the painful parts.  I wish I could share all of the 
postgresql.conf files I've seen so you could better appreciate how people 
torture the poor file in the field.

--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD