Andres Freund writes:
> On Wednesday, September 05, 2012 07:15:52 PM Tom Lane wrote:
>> OK. Do we want to commit this now, or wait till after 9.2.0?
>> My feeling is it's probably okay to include in 9.2.0, but I can see
>> that somebody might want to argue not to. Any objections out there?
> Pe
On Wednesday, September 05, 2012 07:15:52 PM Tom Lane wrote:
> Andres Freund writes:
> > On Sunday, August 26, 2012 06:10:02 PM Andres Freund wrote:
> >> On Saturday, August 25, 2012 06:38:09 AM Tom Lane wrote:
> >>> Surely that's breaking perl's expectations, to more or less the same
> >>> degree
Andres Freund writes:
> On Sunday, August 26, 2012 06:10:02 PM Andres Freund wrote:
>> On Saturday, August 25, 2012 06:38:09 AM Tom Lane wrote:
>>> Surely that's breaking perl's expectations, to more or less the same
>>> degree they're breaking ours?
>> In the referenced bug they agree that this
On Sunday, August 26, 2012 06:10:02 PM Andres Freund wrote:
> On Saturday, August 25, 2012 06:38:09 AM Tom Lane wrote:
> > Andres Freund writes:
> > > Doing a pqsignal(SIGFPE, FloatExceptionHandler) after PERL_SYS_INIT3
> > > seems to work. Is that acceptable?
> >
> > Surely that's breaking perl'
On Saturday, August 25, 2012 06:38:09 AM Tom Lane wrote:
> Andres Freund writes:
> > Doing a pqsignal(SIGFPE, FloatExceptionHandler) after PERL_SYS_INIT3
> > seems to work. Is that acceptable?
>
> Surely that's breaking perl's expectations, to more or less the same
> degree they're breaking ours?
On Saturday, August 25, 2012 06:38:09 AM Tom Lane wrote:
> Andres Freund writes:
> > Doing a pqsignal(SIGFPE, FloatExceptionHandler) after PERL_SYS_INIT3
> > seems to work. Is that acceptable?
>
> Surely that's breaking perl's expectations, to more or less the same
> degree they're breaking ours?
Andres Freund writes:
> Doing a pqsignal(SIGFPE, FloatExceptionHandler) after PERL_SYS_INIT3 seems to
> work. Is that acceptable?
Surely that's breaking perl's expectations, to more or less the same
degree they're breaking ours?
regards, tom lane
--
Sent via pgsql-hack
On Saturday, August 25, 2012 12:15:00 AM Alex Hunsaker wrote:
> On Fri, Aug 24, 2012 at 4:10 PM, Andres Freund
wrote:
> > We probably should workaround that bug anyway given that its a pretty
> > trivial DOS using only a trusted language and it will take quite some
> > time to push out newer perl
On Fri, Aug 24, 2012 at 4:10 PM, Andres Freund wrote:
> We probably should workaround that bug anyway given that its a pretty trivial
> DOS using only a trusted language and it will take quite some time to push out
> newer perl versions even if that bug gets fixed.
>
> Doing a pqsignal(SIGFPE, Fl
On Friday, August 24, 2012 04:53:36 PM Tom Lane wrote:
> Andres Freund writes:
> > ./pod/perl581delta.pod:
> > At startup Perl blocks the SIGFPE signal away since there isn't much
> > Perl can do about it. Previously this blocking was in effect also for
> > programs executed from within Perl. No
On Friday, August 24, 2012 05:09:18 PM Andrew Dunstan wrote:
> On 08/24/2012 10:58 AM, Andres Freund wrote:
> > On Friday, August 24, 2012 04:53:36 PM Tom Lane wrote:
> >> Andres Freund writes:
> >>> ./pod/perl581delta.pod:
> >>> At startup Perl blocks the SIGFPE signal away since there isn't much
On 08/24/2012 10:58 AM, Andres Freund wrote:
On Friday, August 24, 2012 04:53:36 PM Tom Lane wrote:
Andres Freund writes:
./pod/perl581delta.pod:
At startup Perl blocks the SIGFPE signal away since there isn't much
Perl can do about it. Previously this blocking was in effect also for
program
On Friday, August 24, 2012 04:53:36 PM Tom Lane wrote:
> Andres Freund writes:
> > ./pod/perl581delta.pod:
> > At startup Perl blocks the SIGFPE signal away since there isn't much
> > Perl can do about it. Previously this blocking was in effect also for
> > programs executed from within Perl. No
Andres Freund writes:
> ./pod/perl581delta.pod:
> At startup Perl blocks the SIGFPE signal away since there isn't much
> Perl can do about it. Previously this blocking was in effect also for
> programs executed from within Perl. Now Perl restores the original
> SIGFPE handling routine, whatever
On Friday, August 24, 2012 07:33:01 AM Tom Lane wrote:
> Andres Freund writes:
> >> Um ... how exactly can that happen, if the signal is now ignored?
> >
> > My man 2 signal tells me:
> > "According to POSIX, the behavior of a process is undefined after it
> > ignores a SIGFPE, SIGILL, or SIGSEG
Andres Freund writes:
>> Um ... how exactly can that happen, if the signal is now ignored?
> My man 2 signal tells me:
> "According to POSIX, the behavior of a process is undefined after it ignores
> a SIGFPE, SIGILL, or SIGSEGV signal that was not generated by kill(2) or
> raise(3)."
So I gue
On Friday, August 24, 2012 07:19:42 AM Andres Freund wrote:
> On Friday, August 24, 2012 06:55:04 AM Tom Lane wrote:
> > Andres Freund writes:
> > > On Thursday, August 23, 2012 12:17:22 PM Andres Freund wrote:
> > >> While debugging an instance of this bug I noticed that plperlu always
> > >
> >
On Friday, August 24, 2012 06:55:04 AM Tom Lane wrote:
> Andres Freund writes:
> > On Thursday, August 23, 2012 12:17:22 PM Andres Freund wrote:
> >> While debugging an instance of this bug I noticed that plperlu always
> >
> >> removes the SIGFPE handler and sets it to ignore:
> > In fact it can
On Friday, August 24, 2012 06:55:04 AM Tom Lane wrote:
> Andres Freund writes:
> > On Thursday, August 23, 2012 12:17:22 PM Andres Freund wrote:
> >> While debugging an instance of this bug I noticed that plperlu always
> >
> >> removes the SIGFPE handler and sets it to ignore:
> > In fact it can
Andres Freund writes:
> On Thursday, August 23, 2012 12:17:22 PM Andres Freund wrote:
>> While debugging an instance of this bug I noticed that plperlu always
>> removes the SIGFPE handler and sets it to ignore:
> In fact it can be used to crash the server:
Um ... how exactly can that happen, if
On Thursday, August 23, 2012 12:17:22 PM Andres Freund wrote:
> 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.
21 matches
Mail list logo
