Re: all backends (pg7.2.3 / redhat 7.2) die due to unexpected signal 14 (SIGALRM)

From: Mark Aufflick <mark(at)pumptheory(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: all backends (pg7.2.3 / redhat 7.2) die due to unexpected signal 14 (SIGALRM)
Date: 2003-01-28 16:00:05
Message-ID: 9140D39E-32D9-11D7-8948-000393C10932@pumptheory.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)pumptheory(dot)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

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Travis Bauer 2003-01-28 16:01:12 Re: Status of tablespaces
Previous Message Tom Lane 2003-01-28 15:51:05 Re: