On Mon, 26 Oct 2009, Alvaro Herrera wrote:
> But to me this also says that SET PERSISTENT has to go over
> 00initdb.conf and add a comment mark to the setting.
Now you're back to being screwed if the server won't start because of your
change, because you've lost the original working setting.
I think the whole idea of making tools find duplicates and comment them
out as part of making their changes is fundamentally broken, and it's just
going to get worse when switching to use more config files. The fact that
user edits can introduce the same problem, where something is set in more
than one file but only one of them works, means that you can run into this
even if tool editing hygiene is perfect.
A whole new approach is needed if you're going to get rid of this problem
both for tools and for manual edits. What I've been thinking of is making
it possible to run a configuration file check that scans the config
structure exactly the same way as the server, but when it finds a
duplicate setting it produces a warning showing where the one being
ignored is. The patch added near to the end of 8.4 development that
remembers the source file and line number of lines already parsed made
that more straightforward I think. Not having that data is what made this
hard to write when I last considered it a while ago.
If you had that utility, it's a simple jump to then make it run in a
"--fix" mode that just comments out every such ignored duplicate. Now
you've got a solution to this problem that handles any sort of way users
can mess with the configuration. One might even make a case that this
tool should get run just after every time the server starts successfully.
--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD