Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE
Date
Msg-id 52D049FA.3040401@vmware.com
Whole thread Raw
In response to Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE  (Peter Geoghegan <pg@heroku.com>)
Responses Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE  (Peter Geoghegan <pg@heroku.com>)
List pgsql-hackers
On 01/10/2014 08:37 PM, Peter Geoghegan wrote:
> On Fri, Jan 10, 2014 at 7:12 AM, Heikki Linnakangas
> <hlinnakangas@vmware.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



pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Re: Time to do our Triage for 9.4
Next
From: Tom Lane
Date:
Subject: Re: new json funcs