Jan Wieck <JanWieck@Yahoo.com> writes:
> So far the postmaster is not multi-threaded, so it will not create a new
> file and start a backend at the same time. Also, the rename() call is
> supposed to be atomic. So there is allways a file, and it's either the
> old or the new one, never something in between.
(a) rename isn't atomic on Windows, I thought.
(b) I'm still not convinced that there's no race condition in SIGHUP.
(It doesn't help that SIGHUP_handler does SignalChildren() *before*
reading the file for itself --- that looks wrong.)
It occurs to me though that there need be no problem because the only
GUC variables that the postmaster really needs to send to children
are the ones it gets from its command line and environment. Updates
coming from postgresql.conf are not a problem because the children
can get them for themselves (as already-launched backends surely must).
Thus, write_nondefault_variables is misdesigned: it should be called
*once*, not during SIGHUP_handler, and should only be responsible for
writing out values that came from PGC_S_ENV_VAR or PGC_S_ARGV sources
(maybe also PGC_S_OVERRIDE, not sure if postmaster startup uses that).
That way the file never changes after postmaster start and there can
be no race condition. Children will instead have to read
postgresql.conf for themselves during their launch (after they read the
nondefault_variables file), but that's an easy one-line addition.
regards, tom lane