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 <alvhe...@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers