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

On 12/20/2013 10:56 PM, Alvaro Herrera wrote:
> Robert Haas escribió:
>> On Fri, Dec 20, 2013 at 3:39 PM, Heikki Linnakangas
>> <hlinnakangas(at)vmware(dot)com> wrote:
>>> Hmm. If I understand the problem correctly, it's that as soon as another
>>> backend sees the tuple you've inserted and calls XactLockTableWait(), it
>>> will not stop waiting even if we later decide to kill the already-inserted
>>> tuple.
>>>
>>> One approach to fix that would be to release and immediately re-acquire the
>>> transaction-lock, when you kill an already-inserted tuple. Then teach the
>>> callers of XactLockTableWait() to re-check if the tuple is still alive.
>>
>> That particular mechanism sounds like a recipe for unintended consequences.
>
> Yep, what I thought too.
>
> There are probably other ways to make that general idea work though. I
> didn't follow this thread carefully, but is the idea that there would be
> many promise tuples "live" at any one time, or only one? Because if
> there's only one, or a very limited number, it might be workable to
> sleep on that tuple's lock instead of the xact's lock.

Only one.

heap_update() and heap_delete() also grab a heavy-weight lock on the
tuple, before calling XactLockTableWait(). _bt_doinsert() does not, but
it could. Perhaps we can take advantage of that.

- Heikki