Re: Is RecoveryConflictInterrupt() entirely safe in a signal handler?

On Thu, Jan 5, 2023 at 12:33 PM Andres Freund <andres(at)anarazel(dot)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).