Re: Locking B-tree leafs immediately in exclusive mode

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: Locking B-tree leafs immediately in exclusive mode
Дата
Msg-id CANP8+jJzUzyC8_-ospWW3d+GWhqJx6P9ALnZ4+FR511ejCsQWA@mail.gmail.com
обсуждение исходный текст
Ответ на Locking B-tree leafs immediately in exclusive mode  (Alexander Korotkov <a.korotkov@postgrespro.ru>)
Ответы Re: Locking B-tree leafs immediately in exclusive mode  (Alexander Korotkov <a.korotkov@postgrespro.ru>)
Список pgsql-hackers
On 5 June 2018 at 14:45, Alexander Korotkov <a.korotkov@postgrespro.ru> wrote:

> Currently _bt_search() always locks leaf buffer in shared mode (aka BT_READ),
> while caller can relock it later.  However, I don't see what prevents
> _bt_search()
> from locking leaf immediately in exclusive mode (aka BT_WRITE) when required.
> When traversing downlink from non-leaf page of level 1 (lowest level of non-leaf
> pages just prior to leaf pages), we know that next page is going to be leaf.  In
> this case, we can immediately lock next page in exclusive mode if required.
> For sure, it might happen that we didn't manage to exclusively lock leaf in this
> way when _bt_getroot() points us to leaf page.  But this case could be handled
> in _bt_search() by relock.  Please, find implementation of this approach in the
> attached patch.

It's a good idea. How does it perform with many duplicate entries?

-- 
Simon Riggs                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: Concurrency bug in UPDATE of partition-key
Следующее
От: Etsuro Fujita
Дата:
Сообщение: Re: Expression errors with "FOR UPDATE" and postgres_fdw with partitionwise join enabled.