On Thu, Aug 4, 2011 at 19:40, Andrew Dunstan <and...@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()) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
