Re: plperl sigfpe reset can crash the server

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org, Andrew Dunstan <andrew(at)dunslane(dot)net>, Hannu Krosing <hannu(at)2ndquadrant(dot)com>
Subject: Re: plperl sigfpe reset can crash the server
Date: 2012-08-26 16:10:02
Message-ID: 201208261810.02800.andres@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Saturday, August 25, 2012 06:38:09 AM Tom Lane wrote:
> Andres Freund <andres(at)2ndquadrant(dot)com> 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?
In the referenced bug they agree that this is the way forward.

There is the issue of corrupting the perl environment if you manage to
generate a SIGFPE - I couldn't so far - but I see no way other than of
teaching the sigfpe handler to really ignore the error as perl wants.
Not sure if adding such ugliness is acceptable.

The issue that the handler does a longjmp out of external code is a general
problem btw. While pg will probably never create a sigfpe while in anything
critical the same cannot be said about external code.
So anything external with persistent state probably can be made to crash or
similar.

Not sure if there is any real way out of this but making the handler FATAL if
non pg code is running.

Greetings,

Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2012-08-26 17:04:35 Re: PATCH: pgbench - random sampling of transaction written into log
Previous Message Bruce Momjian 2012-08-26 13:47:01 Re: [NOVICE] index refuses to build