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

Hi,

On 2023-01-05 13:21:54 +1300, Thomas Munro wrote:
> 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...

I think we need to accept that this mess can't be fixed in the back
branches. I'd rather get a decent fix sometime in PG16 than a crufty fix in PG
17 that we then backpatch a while later.

> 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.

I think that's a fair point.

> 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).

I'm not too worried about that, particularly because it looks like it'd not be
too hard to lower the overhead further. Arguably allocating memory outside of
mcxt.c is actually a bad thing independent of error handing, because it's
effectively "invisible" to our memory-usage-monitoring facilities.

Greetings,

Andres Freund