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
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 |