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

Date: Mon, 18 Dec 2000 13:18:26 -0500
From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>

Ian Lance Taylor <ian(at)airs(dot)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 a timely response?

I thought about that, but it doesn't seem like a cleaner solution.
Basically you'd have to figure a tradeoff between wasted cycles in
the postmaster and time delay to respond to a crashed backend.
And there's no good tradeoff there. If you have a backend crash,
you want to shut down the other backends ASAP, before they have a
chance to propagate any shared-memory corruption that the failed
backend might've created. The entire exercise is probably pointless
if the postmaster twiddles 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