Excerpts from Hannu Krosing's message of jue ago 04 09:53:40 -0400 2011:
> On Thu, 2011-08-04 at 09:42 -0400, Andrew Dunstan wrote:
> >
> > On 08/04/2011 09:07 AM, Hannu Krosing wrote:
> > > 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?
I vaguely remember looking in the guts of LWP::UserAgent a few years ago
and being rather annoyed at the way it dealt with sigalrm -- it
interfered with other uses we had for the signal. I think we had to run
a patched version of that module or something, not sure.
> > 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.
> >
>
> Sure, but how expensive would it be for pl/perl to do this
> automatically ?
Probably too much, but then since this is an untrusted pl my guess is
that it's OK to request the user to do it only in functions that need
it. I wonder if we could have a check on return from a function that
the sighandler is still what we had before the function was called, to
help discover this problem.
> > I think if you use a perl module that monkeys with the signal handlers
> > for any signal postgres uses all bets are off.
Yeah.
--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support