Re: plperl crash with Debian 6 (64 bit), pl/perlu, libwww and https
От | Hannu Krosing |
---|---|
Тема | Re: plperl crash with Debian 6 (64 bit), pl/perlu, libwww and https |
Дата | |
Msg-id | 1312466020.4917.16.camel@hvost обсуждение исходный текст |
Ответ на | Re: plperl crash with Debian 6 (64 bit), pl/perlu, libwww and https (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: plperl crash with Debian 6 (64 bit), pl/perlu, libwww and https
Re: plperl crash with Debian 6 (64 bit), pl/perlu, libwww and https Re: plperl crash with Debian 6 (64 bit), pl/perlu, libwww and https |
Список | 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 > > >
В списке pgsql-hackers по дате отправления: