Re: Parsing config files in a directory

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(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD