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
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" |