Skip site navigation (1) Skip section navigation (2)

Re: [Glue] Deadlock bug

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: <josh(at)agliodbs(dot)com>
Cc: <joel(at)gluefinance(dot)com>,<magnus(at)hagander(dot)net>, <glue(at)pgexperts(dot)com>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [Glue] Deadlock bug
Date: 2010-08-24 07:03:56
Message-ID: 4C73288C0200002500034A9B@gw.wicourts.gov (view raw or flat)
Thread:
Lists: pgsql-hackers
Josh Berkus  wrote:
 
>> the behavior was the same up to the second UPDATE on Process 2, at
>> which point there was no deadlock.  Process 2 was able to commit,
>> at which point Process 1 failed with:
>>  
>> ERROR:  could not serialize access due to concurrent update
>
> Does this happen immediately, not waiting 2 seconds for deadlock
> checking?
 
The deadlock checking delay never comes into play.  Process 2 would
never be blocked, and Process 1 would fail on the COMMIT of Process
2.
 
Without a detailed scenario I can't comment on exact behavior, but in
a serializable-only environment, with SSI enforcement of RI, you can
count on only having blocking on write/write conflicts, so it would
only be a cycle of those which could ever cause a deadlock.  Anything
where deadlocks currently occur because of SELECT FOR SHARE or SELECT
FOR UPDATE would not have the same deadlock issues.
 
-Kevin


pgsql-hackers by date

Next:From: Heikki LinnakangasDate: 2010-08-24 08:42:49
Subject: Re: Interruptible sleeps (was Re: CommitFest 2009-07: Yay, Kevin! Thanks, reviewers!)
Previous:From: Pavel StehuleDate: 2010-08-24 06:38:24
Subject: Re: patch (for 9.1) string functions

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group