Re: stray SIGALRM - Mailing list pgsql-hackers

From Tom Lane
Subject Re: stray SIGALRM
Date
Msg-id 6620.1371307528@sss.pgh.pa.us
Whole thread Raw
In response to Re: stray SIGALRM  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: stray SIGALRM  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
I wrote:
> Richard Poole <richard@2ndQuadrant.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.

Have you identified the specific place that's giving you trouble?
        regards, tom lane



pgsql-hackers by date:

Previous
From: Amit kapila
Date:
Subject: Re: pluggable compression support
Next
From: Sawada Masahiko
Date:
Subject: Re: Patch for fail-back without fresh backup