Re: Use of signal-unsafe functions from signal handlers

Hi,

On 2022-05-25 09:45:31 +0900, Michael Paquier wrote:
> On Tue, May 24, 2022 at 10:15:55AM -0400, Tom Lane wrote:
> > ereport() itself is just the tip of the iceberg; even if it's safe
> > (which I concur it isn't), there's also the atexit/on_proc_exit
> > functions that are likely to be called during shutdown. So yeah,
> > this coding is not too safe. I'm not sure that getting rid of it
> > would be a net win though, as we'd replace it-might-crash hazards
> > with it-might-never-exit hazards, from bgworkers that neglect to
> > respond to ShutdownRequestPending.

IMO the it-might-never-exit hazard is lower, and can be addressed by the
authors of bgworkers by adding the checks. Whereas the it-might-crash can't
really be addressed well (except reimplementing the signal handler).

It might be worth adding some debugging infrastructure to make it easier to
find spots that don't check various forms of interrupts. If we required a
function to check for things like ShutdownRequestPending, we could check in
that function how long it's been since the last check, subtracting time spent
in WaitLatch etc.

> Hmm. Shouldn't we worry about FloatExceptionHandler() that gets used on
> SIGFPE?

That probably is comparatively low-risk, because SIGFPE is a synchronous
signal. So it'll be triggered in the middle of a floating point math operation
that where divide-by-zero wouldn't be a bug - which we really really shouldn't
have while holding a spinlock or such.

Greetings,

Andres Freund