Tom Lane <tgl@sss.pgh.pa.us> 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
