Tom Lane wrote: > Magnus Hagander <magnus@xxxxxxxxxxxx> writes: >> I'll see if I can repro a case like it to see if the syslogger prevents >> the shared mem from going away when I get back to a dev box. Should be >> enough to just stick a sleep preventing it from stopping, right? > > The syslogger isn't restarted at all during a crash --- this isn't > a race-condition scenario. > > If there is a race condition here, it must be associated with cleanup > for a process continuing to happen after win32_waitpid has already > reported it dead. Hmm ... how much do we trust that bit of spaghetti > around pgwin32_deadchild_callback? What condition is it really waiting > for? I looked that code over a bit again, and it still looks good to me :-) The wait on the handle will fire when a process exits (according to the API). When it does, we post that information to the queue and send SIGCHLD. And the waitpid function pick off the top of the queue. (It's not particularly spaghettified if you know your way around those APIs :-P That's not to say it's impossible there's a bug there, of course) //Magnus
