Win32 deadlock detection not working for Postgres8beta1

"Steve McWilliams" <smcwilliams@EmprisaNetworks.com> writes:

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?

regards, tom lane

"Steve McWilliams" <smcwilliams@EmprisaNetworks.com> writes:

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?

regards, tom lane

Ok, I tried just now setting 'statement_timeout = 1000' in
postgresql.conf, then restarting the service, however it did not prevent
the deadlock from hangining both processes indefinitely, as before.

Btw, I noticed a related thread back in february, I think, from the
postgresql-hackers-win32 list, which discussed a patch to timer.c to fix a
problem with the deadlock detection mechanism. I assume since it was
several months ago however that the fix mentioned should already be
present in the beta1 release.

Steve McWilliams
Software Engineer
Emprisa Networks
703-691-0433x21
smcwilliams@emprisanetworks.com

The information contained in this communication is intended only for the
use of the recipient named above, and may be legally privileged,
confidential and exempt from disclosure under applicable law. If the
reader of this communication is not the intended recipient, you are hereby
notified that any dissemination, distribution or copying of this
communication, or any of its contents, is strictly prohibited. If you have
received this communication in error, please resend this communication to
the sender and delete the original communication and any copy of it from
your computer system. Thank you.

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

"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

[ 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?

It doesn't. This is why the second version of the patch was required,
per http://archives.postgresql.org/pgsql-patches/2004-09/msg00039.php.
It even specifically says this is so it fixes the deadlock issues and
not just statement_timeout :-)

//Magnus

"Magnus Hagander" <mha@sollentuna.net> writes:

How does this fix that case?

It doesn't. This is why the second version of the patch was required,
per http://archives.postgresql.org/pgsql-patches/2004-09/msg00039.php.

Okay, I've applied the right version of the patch now ;-)

regards, tom lane