Re: _bt_split(), and the risk of OOM before its critical section

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: _bt_split(), and the risk of OOM before its critical section
Дата
Msg-id CAH2-WzmDfdoSPP3u0uf=WkYrQKnYJ2F-E_qNTvY9iiQ-5ua4zw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: _bt_split(), and the risk of OOM before its critical section  (Peter Geoghegan <pg@bowt.ie>)
Ответы Re: _bt_split(), and the risk of OOM before its critical section  (Peter Geoghegan <pg@bowt.ie>)
Список pgsql-hackers
On Tue, May 7, 2019 at 6:15 PM Peter Geoghegan <pg@bowt.ie> wrote:
> I suppose I'm biased, but I prefer the new approach anyway. Adding the
> left high key first, and then the right high key seems simpler and
> more logical. It emphasizes the similarities and differences between
> leftpage and rightpage.

I came up with a better way of doing it in the attached revision. Now,
_bt_split() calls _bt_findsplitloc() directly. This makes it possible
to significantly simplify the signature of _bt_split().

It makes perfect sense for _bt_split() to call _bt_findsplitloc()
directly, since _bt_findsplitloc() is already aware of almost every
_bt_split() implementation detail, whereas those same details are not
of interest anywhere else. _bt_findsplitloc() also knows all about
suffix truncation. It's also nice that the actual _bt_truncate() call
is closely tied to the _bt_findsplitloc() call.

-- 
Peter Geoghegan

Вложения

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

Предыдущее
От: "Nasby, Jim"
Дата:
Сообщение: Re: New EXPLAIN option: ALL
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Problems with pg_upgrade and extensions referencing catalog tables/views