Re: Concurrent MERGE

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Concurrent MERGE
Дата
Msg-id 20100805230709.GA2866@anarazel.de
обсуждение исходный текст
Ответ на Re: Concurrent MERGE  (Josh Berkus <josh@agliodbs.com>)
Ответы Re: Concurrent MERGE  (Josh Berkus <josh@agliodbs.com>)
Список 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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Mark Kirkwood
Дата:
Сообщение: Re: Concurrent MERGE
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Concurrent MERGE