Problem with reading startup packet after fork

Peter Eisentraut writes:

I think there will be a race condition around the time of a database
shutdown. After a new child process is created, the system may go into
shutdown mode. However, there is a window where the child won't know
this, because the signal is blocked and/or not set up yet. Note that we
cannot check for shutdown before forking the child because we won't know
yet whether the incoming packet is actually a connection request. We
wouldn't want to send back an error in response to a cancel request, for
example.

Well, cancel that. The child will see the shutdown because the signal is
blocked around the fork. So unless anyone has issues with the latest
patch I posted I will check it in in slightly clean-up form.

--
Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter

Peter Eisentraut <peter_e@gmx.net> writes:

I think there will be a race condition around the time of a database
shutdown. After a new child process is created, the system may go into
shutdown mode. However, there is a window where the child won't know
this, because the signal is blocked and/or not set up yet.

The child will hold off the signal until it can do something about it.
The postmaster will wait for the child to exit. Where's the problem?

Note the following comment in postgres.c:

/*
* Set up signal handlers and masks.
*
* Note that postmaster blocked all signals before forking child process,
* so there is no race condition whereby we might receive a signal
* before we have set up the handler.
*
* Also note: it's best not to use any signals that are SIG_IGNored in
* the postmaster. If such a signal arrives before we are able to
* change the handler to non-SIG_IGN, it'll get dropped. If
* necessary, make a dummy handler in the postmaster to reserve the
* signal.
*/

regards, tom lane