Re: HOLD_INTERRUPTS() vs ProcSignalBarrier

Hi,

On 2022-05-25 14:47:41 +1200, Thomas Munro wrote:
> My question is: do we really need to suppress these non-ereporting
> interrupts in all the places we currently do HOLD_INTERRUPTS()?

Most of those should be fairly short / only block on lwlocks, small amounts of
IO. I'm not sure how much of an issue this is. Are there actually CFIs inside
those HOLD_INTERRUPT sections?

> The reason I'm wondering about this is because the new ProcSignalBarrier
> mechanism has to wait for any HOLD_INTERRUPTS() sections across all backends
> to complete, and that possibly includes long cleanup loops that perform disk
> I/O. While some future ProcSignalBarrier handler might indeed not be safe
> during eg cleanup (perhaps because it can ereport(ERROR)), it is free to
> return false to defer itself until the next CFI.
>
> Concretely, for example, where xact.c holds interrupts:
>
> /* Prevent cancel/die interrupt while cleaning up */
> HOLD_INTERRUPTS();
>
> ... or where dsm_detach does something similar, there is probably no
> reason we should have to delay a ProcSignalBarrier just to accomplish
> what the comment says. Presumably it really just wants to make sure
> it doesn't lose control of the program counter via non-local return.

I don't think that's quite it. There are elog(ERROR) reachable from within
HOLD_INTERRUPTS() sections (it's not a critical section after all). I think
it's more that there's no point in reacting to interrupts in those spots,
because e.g. processing ProcDiePending requires aborting the currently active
transaction.

Greetings,

Andres Freund