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 | 1312480118.25341.6.camel@hvost обсуждение исходный текст |
Ответ на | Re: plperl crash with Debian 6 (64 bit), pl/perlu, libwww and https (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Thu, 2011-08-04 at 10:28 -0400, Tom Lane wrote: > Hannu Krosing <hannu@krosing.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. It then seems that it is a goo idea to treat any fiddling with postgreSQL signal handlers as an error, and rise an ERROR if any signal handler has changed between calling the function and return, in a way suggested by Alvaro This at least forces the developer to pay attention and in case of pl/perl function use something like the { local $SIG{ALRM}; # do LWP stuff here } return 'OK'; trick suggested by Andrew Dunstan I know that this is not the real solution, bu at least it is easier to debug than leaving a round signal handlers pointing to non-existent code, which will trigger next time the deadlock checker tries to run. -- ------- Hannu Krosing PostgreSQL Infinite Scalability and Performance Consultant PG Admin Book: http://www.2ndQuadrant.com/books/
В списке pgsql-hackers по дате отправления: