From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alex Hunsaker <badalex(at)gmail(dot)com> |
Cc: | "David E(dot) Wheeler" <david(at)kineticode(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Hannu Krosing <hannu(at)krosing(dot)net>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: plperl crash with Debian 6 (64 bit), pl/perlu, libwww and https |
Date: | 2011-08-04 23:52:45 |
Message-ID: | 18140.1312501965@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alex Hunsaker <badalex(at)gmail(dot)com> writes:
> On Thu, Aug 4, 2011 at 16:34, David E. Wheeler <david(at)kineticode(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Davis | 2011-08-04 23:56:13 | Re: Transient plans versus the SPI API |
Previous Message | Tom Lane | 2011-08-04 23:38:28 | Re: error: could not find pg_class tuple for index 2662 |