Re: stray SIGALRM

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Richard Poole <richard(at)2ndQuadrant(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: stray SIGALRM
Date: 2013-06-15 14:45:28
Message-ID: 6620.1371307528@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

Have you identified the specific place that's giving you trouble?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Sawada Masahiko 2013-06-15 14:59:01 Re: Patch for fail-back without fresh backup
Previous Message Amit kapila 2013-06-15 13:55:20 Re: pluggable compression support