Re: Problem with reading startup packet after fork - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Problem with reading startup packet after fork
Date
Msg-id 11892.993094112@sss.pgh.pa.us
Whole thread Raw
In response to Problem with reading startup packet after fork  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: "Christopher Kings-Lynne"
Date:
Subject: RE: Setuid functions
Next
From: "Matthew T. O'Connor"
Date:
Subject: Re: Re: Universal admin frontend