Thread: Win32 deadlock detection not working for Postgres8beta1
Hello, 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. I tried uncommenting the deadlock.tx.timeout=1000 value in postgresql.conf, just in case this wasn't already the default value, but it didn't seem to help. 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.
"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.