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();
On 08/09/2011 04:32 PM, Tom Lane wrote:
Andrew Dunstanand...@dunslane.net 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
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
Andrew Dunstan and...@dunslane.net 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
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
Andrew Dunstan and...@dunslane.net 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
On 08/09/2011 12:22 PM, Tom Lane wrote:
Andrew Dunstanand...@dunslane.net 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,
Andrew Dunstan and...@dunslane.net 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
On Sun, Aug 7, 2011 at 17:06, Tim Bunce tim.bu...@pobox.com 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 Mon, Aug 08, 2011 at 01:23:08AM -0600, Alex Hunsaker wrote:
On Sun, Aug 7, 2011 at 17:06, Tim Bunce tim.bu...@pobox.com 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
[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 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
On Fri, Aug 5, 2011 at 08:53, Andrew Dunstan and...@dunslane.net 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
On 08/04/2011 11:23 PM, Alex Hunsaker wrote:
On Thu, Aug 4, 2011 at 19:40, Andrew Dunstanand...@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
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
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 instructions for
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 on Debian 64
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
Hannu Krosing ha...@krosing.net 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
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
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 SIGALARM related
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
On Thu, 2011-08-04 at 10:28 -0400, Tom Lane wrote:
Hannu Krosing ha...@krosing.net 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
On Thu, Aug 4, 2011 at 09:11, Andrew Dunstan and...@dunslane.net 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
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 would
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:
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.
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)
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
On 08/04/2011 08:44 PM, Alex Hunsaker wrote:
On Thu, Aug 4, 2011 at 17:52, Tom Lanet...@sss.pgh.pa.us wrote:
Alex Hunsakerbada...@gmail.com writes:
On Thu, Aug 4, 2011 at 16:34, David E. Wheelerda...@kineticode.com wrote:
On Aug 4, 2011, at 3:09 PM, Alex Hunsaker wrote:
3) local %SIG
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
30 matches
Mail list logo
