Re: SIGFPE handling

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

In response to

Browse pgsql-hackers by date

  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