Re: Re: [SQL] PostgreSQL crashes on me :(

Date: Mon, 18 Dec 2000 13:18:26 -0500  From: Tom Lane <tgl@sss.pgh.pa.us>
  Ian Lance Taylor <ian@airs.com> writes:  >    Any thoughts on a cleaner solution?
  > One way to avoid this race condition is to set a timeout on the  > select.  What is the maximum acceptable time for
atimely response?
 
  I thought about that, but it doesn't seem like a cleaner solution.  Basically you'd have to figure a tradeoff between
wastedcycles in  the postmaster and time delay to respond to a crashed backend.  And there's no good tradeoff there.
Ifyou have a backend crash,  you want to shut down the other backends ASAP, before they have a  chance to propagate any
shared-memorycorruption that the failed  backend might've created.  The entire exercise is probably pointless  if the
postmastertwiddles its thumbs for awhile before killing the  other backends.
 

The timeout is only to catch the case where the child dies between
checking the flag and calling select.

What you really want, of course, is a version of select which lets you
atomically control the signal blocking mask.  That function is
actually specified by the most recent version of POSIX; it's called
pselect; it's just like select, but the last argument is a const
sigset_t * which is atomically passed to sigprocmask(SIG_SETMASK)
around the select (the original signal mask is restored before pselect
returns).  But I don't know which kernels implement it.  There is an
implementation on GNU/Linux, but if the kernel doesn't support it then
it is not truly atomic.

Ian