| From: | Mark Kirkwood <mark(dot)kirkwood(at)catalyst(dot)net(dot)nz> |
|---|---|
| To: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Concurrent MERGE |
| Date: | 2010-08-05 23:06:17 |
| Message-ID: | 4C5B43E9.7090800@catalyst.net.nz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 06/08/10 10:49, 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.
>
>
Hmm - seems to work ok for me (8.3.11 with pgbench schema updating
branches table by bid):
UPDATE branches SET filler='filled' WHERE bid=:x
I get transaction A succeeds, B is rolled back by the deadlock detector,
C left waiting for A to commit or rollback. What do you find?
Cheers
Mark
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2010-08-05 23:07:10 | Re: Concurrent MERGE |
| Previous Message | Tom Lane | 2010-08-05 23:05:01 | Re: including backend ID in relpath of temp rels - updated patch |