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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers