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

On Fri, Dec 20, 2013 at 11:59 PM, Peter Geoghegan <pg(at)heroku(dot)com> wrote:
> I think that the way forward is to refine my design in order to
> upgrade locks from exclusive buffer locks to something else, managed
> by the lock manager but perhaps through an additional layer of
> indirection. As previously outlined, I'm thinking of a new SLRU-based
> granular value locking infrastructure built for this purpose, with
> btree inserters marking pages as having an entry in this table.

I'm working on a revision that holds lmgr page-level exclusive locks
(and buffer pins) across multiple operations. This isn't too
different to what you've already seen, since they are still only held
for an instant. Notably, hash indexes currently quickly grab and
release lmgr page-level locks, though they're the only existing
clients of that infrastructure. I think on reflection that
fully-fledged value locking may be overkill, given the fact that these
locks are only held for an instant, and only need to function as a
choke point for unique index insertion, and only when upserting
occurs.

This approach seems promising. It didn't take me very long to get it
to a place where it passed a few prior test-cases of mine, with fairly
varied input, though the patch isn't likely to be posted for another
few days. I think I can get it to a place where it doesn't regress
regular insertion at all. I think that that will tick all of the many
boxes, without unwieldy complexity and without compromising conceptual
integrity.

I mention this now because obviously time is a factor. If you think
there's something I need to do, or that there's some way that I can
more usefully coordinate with you, please let me know. Likewise for
anyone else following.

--
Peter Geoghegan