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

On Tue, Nov 26, 2013 at 11:32 AM, Heikki Linnakangas
<hlinnakangas@vmware.com> wrote:
> After fixing that bug, I'm getting a correctly-detected deadlock every now
> and then with that test case.

We'll probably want to carefully consider how
predictably/deterministically this occurs.

> Hmm. That's because the trick I used to kill the just-inserted tuple
> confuses a concurrent heap_lock_tuple call. It doesn't expect the tuple it's
> locking to become invisible. Actually, doesn't your patch have the same bug?
> If you're about to lock a tuple in ON DUPLICATE KEY LOCK FOR UPDATE, and the
> transaction that inserted the duplicate row aborts just before the
> heap_lock_tuple() call, I think you'd also see that error.

Yes, that's true. It will occur much more frequently with your
previous revision, but the V4 patch is also affected.

>> To me this seems like a problem with the (potential) total lack of
>> locking that your approach takes (inserting btree unique index tuples
>> as in your patch is a form of value locking...sort of...it's a little
>> hard to reason about as presented). Do you think this might be an
>> inherent problem, or can you suggest a way to make your approach still
>> work?
>
>
> Just garden-variety bugs :-). Attached patch fixes both issues.

Great. I'll let you know what I think.

>> * Doesn't just work with one unique index. Naming a unique index
>> directly in DML, or assuming that the PK is intended seems quite weak
>> to me.

> Totally agreed on that.

Good.

BTW, you keep forgetting to add "expected" output of the new isolation tests.

-- 
Peter Geoghegan