Re: GUC patch for Win32
От | Tom Lane |
---|---|
Тема | Re: GUC patch for Win32 |
Дата | |
Msg-id | 19798.1052401681@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: GUC patch for Win32 (Jan Wieck <JanWieck@Yahoo.com>) |
Ответы |
Re: GUC patch for Win32
|
Список | pgsql-patches |
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
В списке pgsql-patches по дате отправления: