Re: all backends (pg7.2.3 / redhat 7.2) die due to unexpected signal 14 (SIGALRM)
От | Mark Aufflick |
---|---|
Тема | Re: all backends (pg7.2.3 / redhat 7.2) die due to unexpected signal 14 (SIGALRM) |
Дата | |
Msg-id | 9140D39E-32D9-11D7-8948-000393C10932@pumptheory.com обсуждение исходный текст |
Ответ на | Re: all backends (pg7.2.3 / redhat 7.2) die due to unexpected signal 14 (SIGALRM) (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-general |
now that you made me stop and think, I am guessing that the Net::HTTP module must use SIGALRM for handling timeouts... failing finding a way to do without the plperlu trigger altogether, i guess i will have to save and restore the trap - could be messy. On Wednesday, January 29, 2003, at 02:41 AM, Tom Lane wrote: > Mark Aufflick <mark@pumptheory.com> writes: >> ok, so that's not it - i'm definitely not trapping SIGALRM (and btw, >> this was only in the perl client code, which I don;t see how that >> could >> cause the problem anyway - as opposed to in the plperlu function, >> which >> in any case I am pretty sure was not being called when the server >> crashed) > > It wouldn't have to be executing when the crash occurred. If it had > executed at some prior time, and reset the handling of signal 14 at > that > time, then you'd get this failure: > >> DEBUG: server process (pid 20704) was terminated by signal 14 > > whenever the backend process would next have reached a lock timeout. > > I have not dug through the Perl sources to look for mucking with > SIGALRM, but I bet that's what the problem is. > > regards, tom lane
В списке pgsql-general по дате отправления: