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

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: _bt_split(), and the risk of OOM before its critical section
Date: 2019-05-09 22:32:52
Message-ID: CAH2-Wz=gdhhMXcsWXWPS=TjCsK_A4BkPmHmo0-A0JE0+4tG42w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, May 8, 2019 at 3:37 PM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> 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.

I discovered that it even used to work like that until 1997, when
commit 71b3e93c505 added handling of duplicate index tuples. Tom
ripped the duplicate handling stuff out a couple of years later, for
what seemed to me to be very good reasons, but _bt_findsplitloc()
remained outside of _bt_split() until now.

I intend to push ahead with the fix for both v11 and HEAD on Monday.
--
Peter Geoghegan

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-05-09 22:47:58 Re: Unexpected "shared memory block is still in use"
Previous Message Tom Lane 2019-05-09 21:59:39 Re: Unexpected "shared memory block is still in use"