On Thu, Aug 4, 2011 at 19:40, Andrew Dunstan <andrew@dunslane.net> wrote:
> 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.
Well, im not sure about it making LWP totally unusable... You could
always use statement_timeout if you were worried about it blocking
^_^.
> 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?
Maybe the answer is to re-issue the appropriate pqsignals() instead of
doing the perl variant?
For PL/Perl(u) we could still disallow any signals the postmaster
uses, from my quick look that would be: HUP, INT, TERM, QUIT, ALRM,
PIPE, USR1, USR2, FPE. All we would need to do is restore ALRM.
Or am I too paranoid about someone shooting themselves in the foot via
USR1? (BTW you can set signals in plperl, but you can't call alarm()
or kill())
