Re: SIGFPE handler is naive - Mailing list pgsql-hackers

From Tom Lane
Subject Re: SIGFPE handler is naive
Date
Msg-id 28680.1344953584@sss.pgh.pa.us
Whole thread Raw
In response to Re: SIGFPE handler is naive  (Noah Misch <noah@leadboat.com>)
List pgsql-hackers
Noah Misch <noah@leadboat.com> writes:
> On Tue, Aug 14, 2012 at 08:38:44AM -0400, Robert Haas wrote:
>> On Mon, Aug 13, 2012 at 11:52 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> That would depend on how many places there are where SIGFPE is expected.
>>> Are we sure there are any?  Maybe we should just remove the handler and
>>> let SIGFPE be treated as a core dump.

>> No clue.  According to Wikipedia, it is commonly caused by dividing by
>> zero, or by dividing by INT_MIN by -1, resulting in a quotient out of
>> range for the type.  I'd be willing to bet that we have got all the
>> division-by-zero cases patched up just because we try pretty hard to
>> emit the right error message for such cases, but I'm a lot less
>> certain that things like INT_MIN/-1 can't happen anywhere.

> [local] test=# select -9223372036854775808/-1;
> ERROR:  floating-point exception

On reflection I think we should just leave this alone.  If we try to
tighten it up, what we will mainly accomplish is to make the system
less robust, not more, because any place we miss then represents an
easily reproducible DOS attack.

If somebody's dumb enough to think that SIGFPE'ing a backend represents
a supported way of canceling a query, that's his problem not ours.
We don't need to expend large amounts of effort on being sure we slap
his hand.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: SIGFPE handler is naive
Next
From: Alvaro Herrera
Date:
Subject: Re: WIP patch for consolidating misplaced-aggregate checks