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: http://www.postgresql.org/mailpref/pgsql-hackers
