On Tue, Mar 18, 2014 at 4:12 AM, Heikki Linnakangas
<hlinnakan...@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

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to