Thread: Problem with reading startup packet after fork

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.

Any ideas?

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

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
arrivesbefore we are able to    * change the handler to non-SIG_IGN, it'll get dropped.  If    * necessary, make a
dummyhandler in the postmaster to reserve the    * signal.    */
 

        regards, tom lane