Re: [Glue] Deadlock bug - Mailing list pgsql-hackers

From Joel Jacobson
Subject Re: [Glue] Deadlock bug
Date
Msg-id AANLkTinsjN00y3JCWo+rBCs2x2uZx5ti7+wma_tVvd7A@mail.gmail.com
Whole thread Raw
In response to Re: [Glue] Deadlock bug  (Greg Stark <gsstark@mit.edu>)
Responses Re: [Glue] Deadlock bug
List 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

pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: [Glue] Deadlock bug
Next
From: Greg Stark
Date:
Subject: Re: Version Numbering