Re: HOLD_INTERRUPTS() vs ProcSignalBarrier

On Tue, May 24, 2022 at 11:47 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> The concrete example I have in mind is the one created by me in
> 637668fb. That can reach a walkdir() that unlinks a ton of temporary
> files, and has a CFI() in it.

Hmm, I missed that commit, and I have to say I'm a bit doubtful about
it. I don't know what would be better, but using HOLD_INTERRUPTS()
across that much code seems pretty sketch.

> Maybe that particular case should just be using
> HOLD_CANCEL_INTERRUPTS() instead, but that's not quite bulletproof
> enough (see note about parallel interrupts not respecting it), which
> made me start wondering about some other way to say "hold everything
> except non-ereturning interrupts".

Considering the current uses of HOLD_CANCEL_INTERRUPTS(), maybe we
ought to make parallel interrupts respect that flag. It's not obvious
that it's impossible to reach the parallel message handling stuff
while we're in the middle of some wire protocol communication, but
there's no loss either way. If the code is reachable, then it's
incorrect not to hold off parallel message processing at that point,
and if it's unreachable, then it doesn't matter whether we hold off
parallel message processing at that point.

In the case of the DSM cleanup code, we probably shouldn't be
receiving parallel messages while we're trying to tear down a DSM
segment, unless we've got multiple DSM segments around and the one
we're tearing down is not the one being used by parallel query.
However, that's an unlikely scenario, and probably won't cost much if
it happens, and we can't really afford to lose control of the program
counter anyway.

--
Robert Haas
EDB: http://www.enterprisedb.com