Re: plperl crash with Debian 6 (64 bit), pl/perlu, libwww and https
От | Tom Lane |
---|---|
Тема | Re: plperl crash with Debian 6 (64 bit), pl/perlu, libwww and https |
Дата | |
Msg-id | 18140.1312501965@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: plperl crash with Debian 6 (64 bit), pl/perlu, libwww and https (Alex Hunsaker <badalex@gmail.com>) |
Ответы |
Re: plperl crash with Debian 6 (64 bit), pl/perlu, libwww
and https
|
Список | pgsql-hackers |
Alex Hunsaker <badalex@gmail.com> writes: > On Thu, Aug 4, 2011 at 16:34, David E. Wheeler <david@kineticode.com> wrote: >> On Aug 4, 2011, at 3:09 PM, Alex Hunsaker wrote: >>> 3) local %SIG before we call their trigger function. This lets signals >>> still work while "in trigger scope" (like we do for %_TD) >> +1 > That seems to be what most people up-thread thought as well. I dont > see it being too expensive. Ill see if I can whip something up today. The scenario I was imagining was: 1. perl temporarily takes over SIGALRM. 2. while perl function is running, statement_timeout expires, causing SIGALRM to be delivered. 3. perl code is probably totally confused, and even if it isn't, statement_timeout will not be enforced since Postgres won't ever get the interrupt. Even if you don't think statement_timeout is a particularly critical piece of functionality, similar interference with the delivery of, say, SIGUSR1 would be catastrophic. How do you propose to prevent this sort of problem? regards, tom lane
В списке pgsql-hackers по дате отправления: