Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE
От | Heikki Linnakangas |
---|---|
Тема | Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE |
Дата | |
Msg-id | 52D049FA.3040401@vmware.com обсуждение исходный текст |
Ответ на | Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE (Peter Geoghegan <pg@heroku.com>) |
Ответы |
Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE
|
Список | 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 по дате отправления: