On 08/04/2011 11:23 PM, Alex Hunsaker wrote:
> 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
> ^_^.
>
Making users set statement_timeout would be a degradation in utility.
For one thing it means you'd never be able to get back and handle an
unresponsiveness reply. And it would be extra work.
(I don't use LWP in any plperlu code AFAIR, but I do use other things
that could well want to set signals. At the very least a change like
this would mandate a LOT of extra testing by my clients.)
>> 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())
>
This whole thing is a massive over-reaction to a problem we almost
certainly know how to fix fairly simply and relatively painlessly, and
attempts (unsuccessfully, at least insofar as comprehensiveness is
concerned) to fix a problem nobody's actually reported having AFAIK.
cheers
andrew
