Re: Is RecoveryConflictInterrupt() entirely safe in a signal handler? - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: Is RecoveryConflictInterrupt() entirely safe in a signal handler?
Date
Msg-id CA+hUKGJ=_2KUebSbabLLC3q+boqPxpKMWjaFa84_Zfm2xokzZg@mail.gmail.com
Whole thread Raw
In response to Re: Is RecoveryConflictInterrupt() entirely safe in a signal handler?  (Andres Freund <andres@anarazel.de>)
Responses Re: Is RecoveryConflictInterrupt() entirely safe in a signal handler?
List pgsql-hackers
On Thu, Jan 5, 2023 at 12:33 PM Andres Freund <andres@anarazel.de> wrote:
> What about using a version of errsave() that can save FATALs too? We could
> have something roughly like the ProcessInterrupts() in the proposed patch that
> is used from within rcancelrequested(). But instead of actually throwing the
> error, we'd just remember the to-be-thrown-later error, that the next
> "real" CFI would throw.

Right, I contemplated variations on that theme.  I'd be willing to
code something like that to kick the tyres, but it seems like it would
make back-patching more painful?  We're trying to fix bugs here...
Deciding to proceed with #6 (palloc) wouldn't mean we can't eventually
also implement two phase/soft CFI() when we have a potential user, so
I don't really get the painted-into-a-corner argument.  However, it's
all moot if the #6 isn't good enough on its own merits independent of
other hypothetical future users (eg if the per regex_t MemoryContext
overheads are considered too high and can't be tuned acceptably).



pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: Some compiling warnings
Next
From: Andres Freund
Date:
Subject: Re: Split index and table statistics into different types of stats