Thread: Re: [pgsql-hackers-win32] [BUGS] Win32 deadlock detection not working for Postgres8beta1

Re: [pgsql-hackers-win32] [BUGS] Win32 deadlock detection not working for Postgres8beta1

From
"Magnus Hagander"
Date:
>> I am just starting to test out Postgres8 beta1 and notice that the
>> deadlock detection mechanism is not working (under windows
>XP pro with
>> service pack 1).  I am using the version of Postgres built by the
>> PGFoundry project, and have it installed as a service.
>
>> To produce the bug I simply launch 2 separate psql windows, begin a
>> transaction in each, then do staggered 'SELECT ... FOR
>UPDATE' calls on 2
>> different rows in each of the psql windows, in reverse
>order.  The two
>> processes will hang indefinitely.
>
>> The deadlock detection for 8beta1 seems to work fine under
>linux btw.  I
>> have not tried this using a version of 8beta1 built using
>cygwin, but I
>> have run versin 7.4 under cygwin before without this problem.
>
>A reasonable theory about this would be that the timer interrupt isn't
>firing.  Does "statement_timeout" work either?

Bugger. I've found the reason for this - statement_timeout was also
broken. This was broken by the change of how signals are handled on
win32. We disabled APCs completely, but APCs were still used in the
timer emulation... This patch fixes this by re-enabling APCs in the main
check loop. The APC routine used by the timer code is very simple and
will not interfer with the signal stuff (which had problems with socket
calls, as you probably recall).

//Magnus

Attachment
"Magnus Hagander" <mha@sollentuna.net> writes:
>> A reasonable theory about this would be that the timer interrupt isn't
>> firing.  Does "statement_timeout" work either?

> Bugger. I've found the reason for this - statement_timeout was also
> broken. This was broken by the change of how signals are handled on
> win32.

Just outta curiosity, why wasn't that detected by the regression tests?
There is a test that depends on statement_timeout working ...

            regards, tom lane

"Magnus Hagander" <mha@sollentuna.net> writes:
> [ fix broken CHECK_FOR_INTERRUPTS macro ]

Applied.  I see how this might change detection of statement_timeout,
but I do not actually see what it's got to do with deadlock detection.
In the deadlock situation the process that needs to wake up is going
to be blocked on a semaphore, and so it's not going to be executing
CHECK_FOR_INTERRUPTS at all.  How does this fix that case?

            regards, tom lane