Re: spoonbill vs. -HEAD
От | Tom Lane |
---|---|
Тема | Re: spoonbill vs. -HEAD |
Дата | |
Msg-id | 28691.1365034683@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: spoonbill vs. -HEAD (Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>) |
Ответы |
Re: spoonbill vs. -HEAD
|
Список | pgsql-hackers |
Stefan Kaltenbrunner <stefan@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? regards, tom lane
Вложения
В списке pgsql-hackers по дате отправления: