Cleaning up nbtree after logical decoding on standby work

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Cc: "Drouvot, Bertrand" <bertranddrouvot(dot)pg(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>
Subject: Cleaning up nbtree after logical decoding on standby work
Date: 2023-05-26 01:50:31
Message-ID: CAH2-Wz=8Z9qY58bjm_7TAHgtW6RzZ5Ke62q5emdCEy9BAzwhmg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Commit 61b313e4, which prepared index access method code for the
logical decoding on standbys work, made quite a few mechanical
changes. Many routines were revised in order to make sure that heaprel
was available in _bt_getbuf()'s P_NEW (new page allocation) path. But
this went further than it really had to. Many of the changes to nbtree
seem excessive.

We only need a heaprel in those code paths that might end up calling
_bt_getbuf() with blkno = P_NEW. This includes most callers that pass
access = BT_WRITE, and all callers that pass access = BT_READ. This
doesn't have to be haphazard -- there just aren't that many places
that can allocate new nbtree pages. It's just page splits, and new
root page allocations (which are actually a slightly different kind of
page split). The rule doesn't need to be complicated (to be fair it
looks more complicated than it really is).

Attached patch completely removes the changes to _bt_getbuf()'s
signature from 61b313e4. This is possible without any loss of
functionality. The patch splits _bt_getbuf () in two: the code that
handles BT_READ/BT_WRITE stays in _bt_getbuf(), which is now far
shorter. Handling of new page allocation is moved to a new routine
I've called _bt_alloc(). This is clearer in general, and makes it
clear what the rules really are. Any code that might need to call
_bt_alloc() must be prepared for that, by having a heaprel to pass to
it (the slightly complicated case is interrupted page splits).

It's possible that Bertand would have done it this way to begin with
were it not for the admittedly pretty bad nbtree convention around
P_NEW. It would be nice to get rid of P_NEW in the near future, too --
I gather that there was discussion of that in the context of recent
work in this area.

--
Peter Geoghegan

Attachment Content-Type Size
v1-0001-nbtree-Remove-use-of-P_NEW.patch application/octet-stream 49.6 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2023-05-26 02:08:52 Re: Cutting support for OpenSSL 1.0.1 and 1.0.2 in 17~?
Previous Message Jonathan S. Katz 2023-05-26 01:09:57 Re: Docs: Encourage strong server verification with SCRAM