Stephen Harris <lists@spuddy.org> writes:
> On Fri, Nov 17, 2006 at 11:40:36PM -0500, Tom Lane wrote:
>> [ thinks for a bit... ] Another issue is that there'd be a race
>> condition during backend start: if the postmaster tries to kill -PID
>> before the backend has managed to execute setsid, it wouldn't work.
> *ponder* Bugger. Standard solutions (eg try three times with a second
> pause) would mitigate this, but.... Hmm.
I think we could make it work if the postmaster does this:
kill(child_pid, SIGxxx);#ifdef HAVE_SETSID kill(-child_pid, SIGxxx);#endif
In the normal case where the child has already completed setsid(), the
extra signal sent to it should do no harm. In the startup race
condition case, the second kill() accomplishes nothing, and we are
effectively assuming that the child will enable signals and respond to
the first kill before it launches any grandchildren; seems safe enough.
Of course the postmaster should only do this when sending signals that
are likely to be interpreted the same way by random shell scripts as
they are by backends, ie, SIGINT, SIGQUIT, SIGTERM (not, say, SIGUSR1).
This would fix the problem on Unixen with setsid, which should be pretty
much all of them; on any that don't have it, the behavior doesn't
change. Still leaves Windows out in the cold, but I don't see that we
have anything much we can do about it there --- Windows users will just
have to know to kill the child script process instead of the postmaster.
Comments?
regards, tom lane
