On 04/03/2013 12:59 AM, Tom Lane wrote: > 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.
hmm trolling the openbsd cvs history brings up this: http://www.openbsd.org/cgi-bin/cvsweb/src/sys/arch/sparc64/sparc64/machdep.c?r1=1.143;sortby=date#rev1.143 Stefan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
