| From: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: SIGFPE handling |
| Date: | 2026-11-13 06:46:59 |
| Message-ID: | b9b9ac7f-9114-4332-b741-bda4bfe6075d@iki.fi |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 12/11/2026 17:17, Tom Lane wrote:
> Heikki Linnakangas <hlinnaka(at)iki(dot)fi> writes:
>> So, I propose to:
>
>> 1. Change FloatExceptionHandler() to PANIC instead of ERROR
>> 2. Install FloatExceptionHandler() in all processes.
>
> 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);
The "100 / x" can ERROR out, release the lock, and leave shmem in an
unexpected state (the compiler can reorder the assignments, too).
That's probably rare, in most cases it is safe to ERROR out, but I think
we should err on the side of caution.
- Heikki
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Zsolt Parragi | 2026-11-13 07:08:06 | Re: [BUG / PATCH] PG19: VACUUM misestimates reltuples (often 0) after on-access VM setting |
| Previous Message | Andrey Borodin | 2026-11-13 06:39:02 | Re: Possible race condition in pg_basebackup |