Re: [Glue] Deadlock bug
Joel Jacobson <joel@gluefinance.com>
From: Joel Jacobson <joel@gluefinance.com>
To: Greg Stark <gsstark@mit.edu>
Cc: Josh Berkus <josh@agliodbs.com>, glue@pgexperts.com, Magnus Hagander <magnus@hagander.net>, pgsql-hackers@postgresql.org
Date: 2010-08-20T18:57:39Z
Lists: pgsql-hackers
OK. Thanks for the explanation. It's probably the case in general, but in all of my tests (>10), process 2 always aborts. I don't think it is arbitrary in this example, or could it be? 2010/8/20 Greg Stark <gsstark@mit.edu> > On Fri, Aug 20, 2010 at 7:38 PM, Joel Jacobson <joel@gluefinance.com> > wrote: > > If the locking logic would be modified to allow process 2 to go through, > and > > instead abort process 1, I understand some other scenarios would of > course > > be affected, where the situation would be handled in a less optimal way. > > Which process dies when there's a deadlock is pretty much arbitary. > The first process to notice the deadlock will just throw an error > itself. Which one notices first depends on the timing of when the > blocking locks were taken. > > If the second process to get stuck blocks before the first process > checks then the first process will notice first. If it does other > stuff first then the first process will check, not find a deadlock and > go back to sleep. Then the deadlock won't be detected until the second > process checks. > > -- > greg > -- Best regards, Joel Jacobson Glue Finance E: jj@gluefinance.com T: +46 70 360 38 01 Postal address: Glue Finance AB Box 549 114 11 Stockholm Sweden Visiting address: Glue Finance AB Birger Jarlsgatan 14 114 34 Stockholm Sweden