Re: Concurrent MERGE

From: Andres Freund <andres(at)anarazel(dot)de>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Dan Ports <drkp(at)csail(dot)mit(dot)edu>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Concurrent MERGE
Date: 2010-08-05 23:07:10
Message-ID: 20100805230709.GA2866@anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Aug 05, 2010 at 03:49:05PM -0700, Josh Berkus wrote:
>
> > Hm? Please explain what you're talking about.
>
> Transaction A locks 1 and wants a lock on 2
> Transaction B locks 2 and wants a lock on 3
> Transaction C locks 3 and wants a lock on 1
>
> I've never had the deadlock detector successfully deal with the above.
> Let alone a 4-way.
Hm. I have seen 5way deadlocks getting resolved just recently. I can
find the relevant if you find it interesting, but I doubt it is.

> > Not sure I believe this either; one deadlock kills one transaction.
> > If you lose multiple transactions I think you had multiple deadlocks.
>
> Deadlock termination kills *all* of the transactions involved in the
> deadlock; what else could it do? This is as opposed to serialization
> failures, in which usually only one of the transactions involved fails.
Uhm:

postgres=# CREATE TABLE a();
CREATE TABLE
postgres=# CREATE TABLE b();
CREATE TABLE

a: postgres=# BEGIN;LOCK a;

b: postgres=# BEGIN;LOCK b;
BEGIN;LOCK a;

a: postgres=# lock b;

b:
ERROR: deadlock detected
DETAIL: Process 12016 waits for AccessExclusiveLock on relation 24585 of database 11564; blocked by process 12011.
Process 12011 waits for AccessExclusiveLock on relation 24588 of database 11564; blocked by process 12016.
HINT: See server log for query details

Afaik it worked like that for years.

Andres

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-08-05 23:08:45 Re: Concurrent MERGE
Previous Message Mark Kirkwood 2010-08-05 23:06:17 Re: Concurrent MERGE