Re: stray SIGALRM
От | Tom Lane |
---|---|
Тема | Re: stray SIGALRM |
Дата | |
Msg-id | 7418.1371310185@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: stray SIGALRM (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: stray SIGALRM
|
Список | pgsql-hackers |
Andres Freund <andres@2ndquadrant.com> writes: > On 2013-06-15 10:45:28 -0400, Tom Lane wrote: >> 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. Hmm. Personally I'd rather go in the other direction: http://www.postgresql.org/message-id/12819.1183306286@sss.pgh.pa.us but maybe the path of least resistance is to set SA_RESTART for SIGALRM too. Given our current usage of it, there seems no worse harm in allowing kernel calls to restart after a SIGALRM than any other signal. regards, tom lane
В списке pgsql-hackers по дате отправления: