Re: Cross-backend signals and administration (Was: Re: pg_terminate_backend for same-role)

On Sun, Mar 18, 2012 at 01:28, Daniel Farina <daniel(at)heroku(dot)com> wrote:
> Noah offered me these comments:
>> This patch still changes the policy for pg_terminate_backend(), and it does
>> not fix other SIGINT senders like processCancelRequest() and ProcSleep().  If
>> you're concerned about PID-reuse races, audit all backend signalling.  Either
>> fix all such problems or propose a plan to get there eventually.
>
> Is the postmaster signaling its children intrinsically vulnerable to
> PID racing?  Because it controls when it can call wait() or waitpid()
> on child processes, it can unambiguously know that PIDs have not been
> cycled for use.  For this reason, a credible and entirely alternate

As a note for future work, I don't think this assumption holds on
win32. We have a background thread there that picks up "child dead"
events, and posts those on an asynchronous queue (see
pgwin32_deadchild_callback).

And even if we didn't, I'm not sure the *process id* is "blocked"
until you wait on in. There is no "zombie state" for processes on
win32 - it dies, and the process handle becomes signaled (note that
this is also the process *handle*, and not the process id. There may
be multiple handles opened to the same process, but the process itself
goes away as soon as they are switched to signalled mode, even if
nobody was paying attention).

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/