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  (Alex Hunsaker <badalex@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: error: could not find pg_class tuple for index 2662
Следующее
От: Jeff Davis
Дата:
Сообщение: Re: Transient plans versus the SPI API