| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
| Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: SIGFPE handling |
| Date: | 2026-11-13 19:41:01 |
| Message-ID: | 665729.1794598861@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Heikki Linnakangas <hlinnaka(at)iki(dot)fi> writes:
> On 12/11/2026 17:17, Tom Lane wrote:
>> Agree on #2, violently against #1. Why is it an improvement for
>> division-by-zero to take down the entire system?
> It seems unsafe to assume that you can gracefully recover from an ERROR
> on any division-by-zero. Imagine a snippet like this:
> LWLockAcquire(FooLock, LW_EXCLUSIVE);
> shmem->foo = DONE;
> shmem->bar = 100 / x;
> LWLockRelease(FooLock);
This strikes me as a very artificial example. How likely is it that
people will be doing potential division-by-zero within a critical
section? Can't the same argument be used to claim that, say,
OOM within palloc() needs to be a PANIC?
Meanwhile, while it may be true that the core code is careful not to
cause division-by-zero, I really doubt that that statement can be
promised to hold across our extension ecosystem.
I remain of the opinion that changing this will make for a net
decrease in system stability, not an increase.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tomas Vondra | 2026-11-13 19:44:25 | Re: two statement_timeout race conditions |
| Previous Message | Greg Burd | 2026-11-13 19:32:47 | Re: Expanding HOT updates for expression and partial indexes |