I wrote:
> I think the simplest fix is to insert "PG_SETMASK(&UnBlockSig)" into
> StatementCancelHandler() and any other handlers that might exit via
> longjmp. I'm a bit inclined to only do this on platforms where a
> problem is demonstrable, which so far is only OpenBSD. (You'd
> think that all BSDen would have the same issue, but the buildfarm
> shows otherwise.)
BTW, on further thought it seems like maybe this is an OpenBSD bug,
at least in part: what is evidently happening is that the temporary
blockage of SIGINT during the handler persists even after we've
longjmp'd back to the main loop. But we're using sigsetjmp(..., 1)
to establish that longjmp handler --- so why isn't the original signal
mask reinstalled when we return to the main loop?
If (your version of) OpenBSD is getting this wrong, it'd explain why
we've not seen similar behavior elsewhere.
This theory doesn't really exonerate our code completely, because we use
sigsetjmp(..., 0) in PG_TRY, which means that in a code path where we
catch a longjmp and don't PG_RE_THROW it, we could be left with the
signal disabled. I don't believe that is happening in the
isolation-test cases, though.
regards, tom lane
