| From: | Hannu Krosing <hannu(at)krosing(dot)net> |
|---|---|
| To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
| 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:53:40 |
| Message-ID: | 1312466020.4917.16.camel@hvost |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, 2011-08-04 at 09:42 -0400, Andrew Dunstan wrote:
>
> 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.
Sure, but how expensive would it be for pl/perl to do this
automatically ?
> cheers
>
> andrew
>
>
>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Hannu Krosing | 2011-08-04 14:00:25 | Re: Postgres / plpgsql equivalent to python's getattr() ? |
| Previous Message | Hannu Krosing | 2011-08-04 13:47:03 | Re: plperl crash with Debian 6 (64 bit), pl/perlu, libwww and https |