Re: stray SIGALRM

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: stray SIGALRM
Дата
Msg-id 6620.1371307528@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: stray SIGALRM  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: stray SIGALRM  (Andres Freund <andres@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Amit kapila
Дата:
Сообщение: Re: pluggable compression support
Следующее
От: Sawada Masahiko
Дата:
Сообщение: Re: Patch for fail-back without fresh backup