Re: SIGFPE handling

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

In response to

Browse pgsql-hackers by date

  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