From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Hannu Krosing <hannu(at)2ndQuadrant(dot)com> |
Cc: | Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: plperl crash with Debian 6 (64 bit), pl/perlu, libwww and https |
Date: | 2011-08-04 13:42:31 |
Message-ID: | 4E3AA1C7.4020001@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 08/04/2011 09:07 AM, Hannu Krosing wrote:
> Hi
>
> I have been helping some people to debug a SIGALARM related crash
> induced by using pl/perlu http get functionality
>
> I have been so far able to repeat the crash only on Debian 64 bit
> computers. DB create script and instructions for reproducing the crash
> attached
>
> The crash is related to something leaving begind a bad SIGALARM handler,
> as it can be (kind of) fixed by resetting sigalarm to nothing using perl
> function
So doesn't this look like a bug in the perl module that sets the signal
handler and doesn't restore it?
What happens if you wrap the calls to the module like this?:
{
local $SIG{ALRM};
# do LWP stuff here
}
return 'OK';
That should restore the old handler on exit from the block.
I think if you use a perl module that monkeys with the signal handlers
for any signal postgres uses all bets are off.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Hannu Krosing | 2011-08-04 13:47:03 | Re: plperl crash with Debian 6 (64 bit), pl/perlu, libwww and https |
Previous Message | Kevin Grittner | 2011-08-04 13:40:28 | Re: Compressing the AFTER TRIGGER queue |