Stephen Harris 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);
kill(-child_pid, SIGxxx);

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.


regards, tom lane

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 12 of 35 | next ›
Discussion Overview
grouppgsql-hackers @
postedNov 17, '06 at 10:03p
activeNov 30, '06 at 9:40p



site design / logo © 2022 Grokbase