Re: plperl crash with Debian 6 (64 bit), pl/perlu, libwww and https

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Hannu Krosing <hannu(at)krosing(dot)net>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, 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 14:28:45
Message-ID: 8681.1312468125@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hannu Krosing <hannu(at)krosing(dot)net> writes:
> On Thu, 2011-08-04 at 09:42 -0400, Andrew Dunstan wrote:
>> On 08/04/2011 09:07 AM, Hannu Krosing wrote:
>>> The crash is related to something leaving begind a bad SIGALARM handler,

>> So doesn't this look like a bug in the perl module that sets the signal
>> handler and doesn't restore it?
>> 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 ?

How can anything like that possibly work with any reliability
whatsoever? If the signal comes in, you don't know whether it was
triggered by the event Postgres expected, or the event the perl module
expected, and hence there's no way to deliver it to the right signal
handler (not that the code you're describing is even trying to do that).

What *I'd* like is a way to prevent libperl from touching the host
application's signal handlers at all. Sadly, Perl does not actually
think of itself as an embedded library, and therefore thinks it owns all
resources of the process and can diddle them without anybody's
permission.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2011-08-04 14:34:44 Re: plperl crash with Debian 6 (64 bit), pl/perlu, libwww and https
Previous Message Alvaro Herrera 2011-08-04 14:25:49 Re: plperl crash with Debian 6 (64 bit), pl/perlu, libwww and https