From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Noah Misch <noah(at)leadboat(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: SIGFPE handler is naive |
Date: | 2012-08-14 12:38:44 |
Message-ID: | CA+Tgmoa68QTGpo8n2McCifZR3-W5kcuxJJ8Gg-EkciFXsJ=N1A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Aug 13, 2012 at 11:52 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Mon, Aug 13, 2012 at 10:14 PM, Noah Misch <noah(at)leadboat(dot)com> wrote:
>>> Overall, though, I think it best to plug this. We could set a flag before
>>> each operation, like evaluation of SQL arithmetic, for which SIGFPE is normal.
>
>> Yeah, that's what I thought of, too. It seems like it'd be a lot of
>> work to get there, though.
>
> 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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2012-08-14 12:40:06 | Re: SIGFPE handler is naive |
Previous Message | Kevin Grittner | 2012-08-14 11:25:59 | Re: default_isolation_level='serializable' crashes on Windows |