Re: _bt_split(), and the risk of OOM before its critical section - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: _bt_split(), and the risk of OOM before its critical section
Date
Msg-id CAH2-WzmDfdoSPP3u0uf=WkYrQKnYJ2F-E_qNTvY9iiQ-5ua4zw@mail.gmail.com
Whole thread Raw
In response to Re: _bt_split(), and the risk of OOM before its critical section  (Peter Geoghegan <pg@bowt.ie>)
Responses Re: _bt_split(), and the risk of OOM before its critical section  (Peter Geoghegan <pg@bowt.ie>)
List 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

Attachment

pgsql-hackers by date:

Previous
From: "Nasby, Jim"
Date:
Subject: Re: New EXPLAIN option: ALL
Next
From: Tom Lane
Date:
Subject: Re: Problems with pg_upgrade and extensions referencing catalog tables/views