On 08/04/2011 08:44 PM, Alex Hunsaker wrote:
On Thu, Aug 4, 2011 at 17:52, Tom Lane<t...@sss.pgh.pa.us> wrote:
Alex Hunsaker<bada...@gmail.com> writes:
On Thu, Aug 4, 2011 at 16:34, David E. Wheeler<da...@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:
[ $SIG{ALRM} + statement timeout-- what happens?]
....
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.
Yipes, I see your point.
How do you propose to prevent this sort of problem?
Well, I think that makes it unworkable.
So back to #1 or #2.
For plperlu sounds like we are going to need to disallow setting _any_
signals (minus __DIE__ and __WARN__). I should be able to make it so
when you try it gives you a warning something along the lines of
"plperl can't set signal handlers, ignoring...".
For plperl I think we should probably do the same. It seems like
Andrew might disagree though? Anyone else want to chime in on if
plperl lets you muck with signal handlers?
Im not entirely sure how much of this is workable, I still need to go
through perl's guts and see. At the very worst I think we can mark
each signal handler that is exposed in %SIG readonly (which would mean
we would die instead of warning), but I think I can make the warning
variant workable as well.
I also have not dug deep enough to know how to handle __WARN__ and
__DIE__ (and exactly what limitations allowing those will impose). I
still have some work at $day_job before I can really dig into this.
Let's slow down a bit. Nobody that we know of has encountered the
problem Tom's referring to, over all the years plperlu has been
available. The changes you're proposing have the potential to downgrade
the usefulness of plperlu considerably without fixing anything that's
known to be an actual problem. Instead of fixing a problem caused by
using LWP you could well make LWP totally unusable from plperlu.
And it still won't do a thing about signal handlers installed by C code.
And plperlu would be the tip of the iceberg. What about all the other
PLs, not to mention non-PL loadable modules?
But we *can* fix the original problem reported, namely failure to
restore signal handlers on function exit, with very little downside
(assuming it's shown to be fairly cheap).
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
