Tom Lane <[EMAIL PROTECTED]> writes: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > > The idea here is the when you comment something out, it should restore > > its default. Right now it keeps the previously uncommented out value, > > which confuses people. > > But the contrary position is that a comment is a comment, not something > that should act to change the state of the postmaster.
As someone else said I think there's a fundamental difference here on what "reloading" means. In every other system I've seen, when you "reload" a config file the system goes through the exact same process (semantically at least) that it does when starting up. Ie, it start with a fresh slate of defaults and loads the config file which sets parameters and overrides those defaults. The Postgres way is that it remembers the old values and loads the config files on top of that. You end up with a situation equivalent to having the new config file tacked onto the old one. The problem with the Postgres semantics is that you end up with a system in a state that isn't represented in either the new config file or the old one. This means if you restart Postgres will come up in a different state from what was running. The conventional semantics give the sysadmin a nice guarantee that he or she can reload the config file and if it works then he can be confident that the server is using the same configuration that it will be using after a restart. I fear a lot of sysadmins after being bitten by this confusion once will decide that it's unsafe to simply reload config files in Postgres and it's necessary to stop and start the server to be sure the new config file is correct and won't cause problems after a subsequent restart. -- greg ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly