On 04/04/2013 02:18 AM, Tom Lane wrote:
Stefan Kaltenbrunner <ste...@kaltenbrunner.cc> writes:
On 04/03/2013 12:59 AM, Tom Lane wrote:
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
That's about alternate signal stacks, which we're not using.
I put together a simple test program (attached) and tried it on
spoonbill, and it says that the signal *does* get unblocked when control
returns to the sigsetjmp(...,1). So now I'm really confused. Somehow
the results we're getting in a full-fledged backend do not match up with
the results gotten by this test program ... but why?
as a followup to this - I spend some time upgrading spoonbill to the
lastest OpenBSD release (5.3) the other day and it seems to be able to
pass a full regression test run now on a manual run. I will add it to
the regular reporting schedule again, but it seems at least part of the
problem is/was an Operating system level issue that got fixed in either
5.2 or 5.3 (spoonbill was on 5.1 before).
Stefan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
