Re: B-tree descend for insertion locking - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: B-tree descend for insertion locking
Date
Msg-id CAM3SWZSN0mmrdFeNw+Vuteg0M-=EB4ffUcFiFUSYDArOgWV+pA@mail.gmail.com
Whole thread Raw
In response to B-tree descend for insertion locking  (Heikki Linnakangas <hlinnakangas@vmware.com>)
List pgsql-hackers
On Tue, Mar 18, 2014 at 4:12 AM, Heikki Linnakangas
<hlinnakangas@vmware.com> wrote:
> See attached patch. The new contract of _bt_getroot is a bit weird: it locks
> the returned page in the requested lock-mode, shared or exclusive, if the
> root page was also the leaf page. Otherwise it's locked in shared mode
> regardless off the requested lock mode. But OTOH, the new contract for
> _bt_search() is more clear now: it actually locks the returned page in the
> requested mode, where it used to only use the access parameter to decide
> whether to create a root page if the index was empty.

I had considered this myself, and am under the impression that the
only reason things work this way is because it makes the interface of
_bt_getroot() clearer. I think what you propose is logical, and you
should pursue it, but fwiw I'm not convinced that you've really
simplified _bt_search(). However, you have kind of made _bt_search()
into something that succinctly represents what is useful about Lehman
and Yao as compared to earlier concurrent locking techniques, and
that's a good thing. I would probably have remarked on that in the
comments if I were you. I certainly would not have left out some
reference to L&Y. You've removed an existing one where the lock
escalation occurs, emphasizing that it's safe, and I'd like to see you
at least compensate for that.


-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Re: GSoC proposal. Index-only scans for GIST
Next
From: Heikki Linnakangas
Date:
Subject: Re: pg_archivecleanup bug