Hi,
While debugging an instance of this bug I noticed that plperlu always removes
the SIGFPE handler and sets it to ignore:
andres@awork2:~$ psql -p 5435 -U postgres -h /var/run/postgresql test
Timing is on.
psql (9.1devel, server 9.1.5)
Type "help" for help.
test=# SELECT pg_backend_pid();
p
Andrew Dunstan writes:
> On 08/09/2011 04:32 PM, Tom Lane wrote:
>> [ shrug... ] Installing a perl module that mucks with the signal
>> handlers is in the "don't do that" category. A kluge such as you
>> suggest will not get it out of that category; all it will do is add
>> useless overhead for
On Aug 10, 2011, at 9:44 AM, Andrew Dunstan wrote:
> After some experimentation, I found that, at least on my system, if LWP uses
> Crypt::SSLeay for https requests then it sets an alarm handler, but if
> instead it uses IO::Socket::SSL an alarm handler is not set. So the answer to
> the OP's o
On 08/09/2011 04:32 PM, Tom Lane wrote:
Andrew Dunstan writes:
On 08/09/2011 12:22 PM, Tom Lane wrote:
No. As I pointed out upthread, the instant somebody changes the SIGALRM
handler to a non-Postgres-aware one, you are already at risk of failure.
Setting it back later is just locking the b
Andrew Dunstan writes:
> On 08/09/2011 12:22 PM, Tom Lane wrote:
>> No. As I pointed out upthread, the instant somebody changes the SIGALRM
>> handler to a non-Postgres-aware one, you are already at risk of failure.
>> Setting it back later is just locking the barn door after the horses
>> left.
On 08/09/2011 12:22 PM, Tom Lane wrote:
Andrew Dunstan writes:
On 08/08/2011 05:03 AM, Tim Bunce wrote:
After giving it some more thought it seems reasonable to simply force the
SIGALRM handler back to postgres when a plperlu function returns:
pqsignal(SIGALRM, handle_sig_alarm);
Maybe we n
Andrew Dunstan writes:
> On 08/08/2011 05:03 AM, Tim Bunce wrote:
>> After giving it some more thought it seems reasonable to simply force the
>> SIGALRM handler back to postgres when a plperlu function returns:
>> pqsignal(SIGALRM, handle_sig_alarm);
> Maybe we need to do this in some more cent
On 08/08/2011 05:03 AM, Tim Bunce wrote:
After giving it some more thought it seems reasonable to simply force the
SIGALRM handler back to postgres when a plperlu function returns:
pqsignal(SIGALRM, handle_sig_alarm);
Maybe we need to do this in some more centralized spot. It seems
On Mon, Aug 08, 2011 at 01:23:08AM -0600, Alex Hunsaker wrote:
> On Sun, Aug 7, 2011 at 17:06, Tim Bunce wrote:
>
> > Localizing an individual element of %SIG works fine.
> > In C that's something like this (untested):
> >
> > hv = gv_fetchpv("SIG", 0, SVt_PVHV);
> > keysv = ...SV containin
On Sun, Aug 7, 2011 at 17:06, Tim Bunce wrote:
> On Sat, Aug 06, 2011 at 12:37:28PM -0600, Alex Hunsaker wrote:
>> ...
>> Find attached a version that does the equivalent of local %SIG for
>> each pl/perl(u) call.
>
>> + gv = gv_fetchpv("SIG", 0, SVt_PVHV);
>> + save_hash(gv);
On 08/07/2011 07:06 PM, Tim Bunce wrote:
After a little digging and some discussion on the #p5p channel [thanks
to ilmari++ leont++ and sorear++ for their help] it seems that local(%SIG)
doesn't do what you might expect. The %SIG does become empty but the OS
level handlers, even those installe
[I've included a summary of the thread and Bcc'd this to perl5-porters
for a sanity check. Please trim heavily when replying.]
On Thu, Aug 04, 2011 at 09:42:31AM -0400, Andrew Dunstan wrote:
>
> So doesn't this look like a bug in the perl module that sets the
> signal handler and doesn't restore
On Fri, Aug 5, 2011 at 08:53, Andrew Dunstan wrote:
>
>
> On 08/04/2011 11:23 PM, Alex Hunsaker wrote:
>>
>> [ ... don't let people set signal handlers postgres sets ]
>
> This whole thing is a massive over-reaction to a problem we almost certainly
> know how to fix fairly simply and relatively pa
On 08/04/2011 11:23 PM, Alex Hunsaker wrote:
On Thu, Aug 4, 2011 at 19:40, Andrew Dunstan 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 dow
On Thu, Aug 4, 2011 at 19:40, Andrew Dunstan 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 considera
On 08/04/2011 08:44 PM, Alex Hunsaker wrote:
On Thu, Aug 4, 2011 at 17:52, Tom Lane wrote:
Alex Hunsaker writes:
On Thu, Aug 4, 2011 at 16:34, David E. Wheeler wrote:
On Aug 4, 2011, at 3:09 PM, Alex Hunsaker wrote:
3) local %SIG before we call their trigger function. This lets signals
s
On Thu, Aug 4, 2011 at 17:52, Tom Lane wrote:
> Alex Hunsaker writes:
>> On Thu, Aug 4, 2011 at 16:34, David E. Wheeler 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"
Alex Hunsaker writes:
> On Thu, Aug 4, 2011 at 16:34, David E. Wheeler 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 wha
On Thu, Aug 4, 2011 at 16:34, David E. Wheeler wrote:
> On Aug 4, 2011, at 3:09 PM, Alex Hunsaker wrote:
>
>> Mainly the options im thinking about are:
>> 1) if anyone touches %SIG die
>> 2) turn %SIG into a regular hash so people can set/play with %SIG, but
>> it has no real effect.
>
> These wou
On Aug 4, 2011, at 3:09 PM, Alex Hunsaker wrote:
> Mainly the options im thinking about are:
> 1) if anyone touches %SIG die
> 2) turn %SIG into a regular hash so people can set/play with %SIG, but
> it has no real effect.
These would disable stuff like $SIG{__WARN__} and $SIG{__DIE__}, which wou
On Thu, Aug 4, 2011 at 09:11, Andrew Dunstan wrote:
>> What *I'd* like is a way to prevent libperl from touching the host
>> application's signal handlers at all. Sadly, Perl does not actually
>> think of itself as an embedded library, and therefore thinks it owns all
>> resources of the process
On Thu, 2011-08-04 at 10:28 -0400, Tom Lane wrote:
> Hannu Krosing writes:
> > On Thu, 2011-08-04 at 09:42 -0400, Andrew Dunstan wrote:
> >> On 08/04/2011 09:07 AM, Hannu Krosing wrote:
> >>> The crash is related to something leaving begind a bad SIGALARM handler,
>
> >> So doesn't this look like
On 08/04/2011 10:28 AM, Tom Lane wrote:
How can anything like that possibly work with any reliability
whatsoever? If the signal comes in, you don't know whether it was
triggered by the event Postgres expected, or the event the perl module
expected, and hence there's no way to deliver it to the
On Aug 4, 2011, at 5:25 PM, Alvaro Herrera wrote:
> Excerpts from Hannu Krosing's message of jue ago 04 09:53:40 -0400 2011:
>> On Thu, 2011-08-04 at 09:42 -0400, Andrew Dunstan wrote:
>>>
>>> On 08/04/2011 09:07 AM, Hannu Krosing wrote:
>
I have been helping some people to debug a SIGALAR
On 08/04/2011 09:53 AM, Hannu Krosing wrote:
What happens if you wrap the calls to the module like this?:
{
local $SIG{ALRM};
# do LWP stuff here
}
return 'OK';
That should restore the old handler on exit from the block.
I think if you use a perl modu
Hannu Krosing writes:
> On Thu, 2011-08-04 at 09:42 -0400, Andrew Dunstan wrote:
>> On 08/04/2011 09:07 AM, Hannu Krosing wrote:
>>> The crash is related to something leaving begind a bad SIGALARM handler,
>> So doesn't this look like a bug in the perl module that sets the signal
>> handler and
Excerpts from Hannu Krosing's message of jue ago 04 09:53:40 -0400 2011:
> On Thu, 2011-08-04 at 09:42 -0400, Andrew Dunstan wrote:
> >
> > On 08/04/2011 09:07 AM, Hannu Krosing wrote:
> > > I have been helping some people to debug a SIGALARM related crash
> > > induced by using pl/perlu http get
On Thu, 2011-08-04 at 09:42 -0400, Andrew Dunstan wrote:
>
> On 08/04/2011 09:07 AM, Hannu Krosing wrote:
> > Hi
> >
> > I have been helping some people to debug a SIGALARM related crash
> > induced by using pl/perlu http get functionality
> >
> > I have been so far able to repeat the crash only o
On Thu, 2011-08-04 at 15:07 +0200, Hannu Krosing wrote:
> Hi
>
> I have been helping some people to debug a SIGALARM related crash
> induced by using pl/perlu http get functionality
>
> I have been so far able to repeat the crash only on Debian 64 bit
> computers. DB create script and instruction
On 08/04/2011 09:07 AM, Hannu Krosing wrote:
Hi
I have been helping some people to debug a SIGALARM related crash
induced by using pl/perlu http get functionality
I have been so far able to repeat the crash only on Debian 64 bit
computers. DB create script and instructions for reproducing the
Hi
I have been helping some people to debug a SIGALARM related crash
induced by using pl/perlu http get functionality
I have been so far able to repeat the crash only on Debian 64 bit
computers. DB create script and instructions for reproducing the crash
attached
The crash is related to somethin
31 matches
Mail list logo
