Stephen Harris writes:
pause) would mitigate this, but.... Hmm.
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[ 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.
pause) would mitigate this, but.... Hmm.
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
