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

On 01/14/2014 12:20 PM, Peter Geoghegan wrote:
> I think that the prevention of unprincipled deadlocking is all down to
> this immediately prior piece of code, at least in those test cases:

> !             /*
> !              * in insertion by other.
> !              *
> !              * Before returning true, check for the special case that the
> !              * tuple was deleted by the same transaction that inserted it.
> !              * Such a tuple will never be visible to anyone else, whether
> !              * the transaction commits or aborts.
> !              */
> !             if (!(tuple->t_infomask & HEAP_XMAX_INVALID) &&
> !                 !(tuple->t_infomask & HEAP_XMAX_COMMITTED) &&
> !                 !(tuple->t_infomask & HEAP_XMAX_IS_MULTI) &&
> !                 !HEAP_XMAX_IS_LOCKED_ONLY(tuple->t_infomask) &&
> !                 HeapTupleHeaderGetRawXmax(tuple) == HeapTupleHeaderGetRawXmin(tuple))
> !             {
> !                 return false;
> !             }
>
> But why should it be acceptable to change the semantics of dirty
> snapshots like this, which previously always returned true when
> control reached here? It is a departure from their traditional
> behavior, not limited to clients of this new promise tuple
> infrastructure. Now, it becomes entirely a matter of whether we tried
> to insert before or after the deleting xact's deletion (of a tuple it
> originally inserted) as to whether or not we block. So in general we
> don't get to "keep our old value locks" until xact end when we update
> or delete.

Hmm. So the scenario would be that a process inserts a tuple, but kills 
it again later in the transaction, and then re-inserts the same value. 
The expectation is that because it inserted the value once already, 
inserting it again will not block. Ie. inserting and deleting a tuple 
effectively acquires a value-lock on the inserted values.

> Even if you don't consider this a bug for existing dirty
> snapshot clients (I myself do - we can't rely on deleting a row and
> re-inserting the same values now, which could be particularly
> undesirable for updates),

Yeah, it would be bad if updates start failing because of this. We could 
add a check for that, and return true if the tuple was updated rather 
than deleted.

> I have already described how we can take
> advantage of deleting tuples while still holding on to their "value
> locks" [1] to Andres. I think it'll be very important for multi-master
> conflict resolution. I've already described this useful property of
> dirty snapshots numerous times on this thread in relation to different
> aspects, as it happens. It's essential.

I didn't understand that description.

> Anyway, I guess you're going to need an infomask bit to fix this, so
> you can differentiate between 'promise' tuples and 'proper' tuples.

Yeah, that's one way. Or you could set xmin to invalid, to make the 
killed tuple look thoroughly dead to everyone.

> Those are in short supply. I still think this problem is more or less
> down to a modularity violation, and I suspect that this is not the
> last problem that will be found along these lines if we continue to
> pursue this approach.

You have suspected that many times throughout this thread, and every 
time there's been a relatively simple solutions to the issues you've 
raised. I suspect that's also going to be true for whatever mundane next 
issue you come up with.

- Heikki