Re: stray SIGALRM

On 2013-06-15 10:45:28 -0400, Tom Lane wrote:
> I wrote:
> > Richard Poole <richard(at)2ndQuadrant(dot)com> writes:
> >> This behaviour appears in 6ac7facdd3990baf47efc124e9d7229422a06452 as a
> >> side-effect of speeding things up by getting rid of setitimer() calls;
> >> it's not obvious what's a good way to fix it without losing the benefits
> >> of that commit.
>
> > Ugh. It doesn't sound very practical to try to guarantee that every
> > single kernel call in the backend is set up to recover from EINTR,
> > even though ideally they should all be able to cope.
>
> On reflection though, we *do* need to make them cope, because even
> without lazy SIGALRM disable, any such place is still at risk. We
> surely must allow for the possibility of SIGHUP arriving at any instant,
> for example.

All signal handlers we register, including SIGHUP, but the one for
SIGALRM set SA_RESTART... I wonder if we can rejigger things so we don't
need that? I am not sure if there's still a reason for that decision
inside the backend.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services