Re: B-tree descend for insertion locking
От | Peter Geoghegan |
---|---|
Тема | Re: B-tree descend for insertion locking |
Дата | |
Msg-id | CAM3SWZSN0mmrdFeNw+Vuteg0M-=EB4ffUcFiFUSYDArOgWV+pA@mail.gmail.com обсуждение исходный текст |
Ответ на | B-tree descend for insertion locking (Heikki Linnakangas <hlinnakangas@vmware.com>) |
Список | 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 по дате отправления: