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
|
Список | 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 по дате отправления: