Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE

From: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
To: Peter Geoghegan <pg(at)heroku(dot)com>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE
Date: 2014-01-10 19:28:58
Message-ID: 52D049FA.3040401@vmware.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 01/10/2014 08:37 PM, Peter Geoghegan wrote:
> On Fri, Jan 10, 2014 at 7:12 AM, Heikki Linnakangas
> <hlinnakangas(at)vmware(dot)com> wrote:
>> I'm getting deadlocks with this patch, using the test script you posted
>> earlier in
>> http://www.postgresql.org/message-id/CAM3SWZQh=8xNVgbBzYHJeXUJBHwZNjUTjEZ9t-DBO9t_mX_8Kw@mail.gmail.com.
>> Am doing something wrong, or is that a regression?
>
> Yes. The point of that test case was that it made your V1 livelock
> (which you fixed), not deadlock in a way detected by the deadlock
> detector, which is the correct behavior.

Oh, ok. Interesting. With the patch version I posted today, I'm not
getting deadlocks. I'm not getting duplicates in the table either, so it
looks like the promise tuple approach somehow avoids the deadlocks,
while the btreelock patch does not.

Why does it deadlock with the btreelock patch? I don't see why it
should. If you have two backends inserting a single tuple, and they
conflict, one of them should succeed to insert, and the other one should
update.

- Heikki

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-01-10 19:31:31 Re: new json funcs
Previous Message Josh Berkus 2014-01-10 19:28:36 Re: Time to do our Triage for 9.4