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

On Wed, Sep 25, 2013 at 8:19 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> This thread had a lot of discussion about bloating. I wonder, does the
> code check to see if there is a matching row _before_ adding any data?

That's pretty much what the patch does.

> Our test-and-set code first checks to see if the lock is free, then if
> it it is, it locks the bus and does a test-and-set. Couldn't we easily
> check the indexes for matches before doing any locking? It seems that
> would avoid bloat in most cases, and allow for a simpler implementation.

The value locks are only really necessary for getting consensus across
unique indexes on whether or not to go forward, and to ensure that
insertion can *finish* unhindered once we're sure that's appropriate.
Once we've committed to insertion, we hold them across heap tuple
insertion and release each value lock as part of something close to
conventional btree index tuple insertion (with an index tuple with an
ordinary heap pointer inserted). I believe that all schemes proposed
to date have some variant of what could be described as value locking,
such as ordinary index tuples inserted speculatively.

Value locks are *not* held during row locking, and an attempt at row
locking is essentially opportunistic for various reasons (it boils
down to the fact that re-verifying uniqueness outside of the btree
code is very unappealing, and in any case would naturally sometimes be
insufficient - what happens if key values change across row
versions?). This might sound a bit odd, but is in a sense no different
to the current state of affairs, where the first waiter on a blocking
xact that inserted a would-be duplicate is not guaranteed to be the
first to get a second chance at inserting. I don't believe that there
are any significant additional lock starvation hazards.

In the simple case where there is a conflicting tuple that's already
committed, value locks above and beyond what the btree code does today
are unnecessary (provided the attempt to acquire a row lock is
eventually successful, which mostly means that no one else has
updated/deleted - otherwise we try again).

--
Peter Geoghegan