Re: Cleaning up nbtree after logical decoding on standby work

Peter Geoghegan <pg@bowt.ie>

From: Peter Geoghegan <pg@bowt.ie>
To: Andres Freund <andres@anarazel.de>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>, Michael Paquier <michael@paquier.xyz>, Alvaro Herrera <alvherre@alvh.no-ip.org>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, "Drouvot, Bertrand" <bertranddrouvot.pg@gmail.com>
Date: 2023-06-08T01:10:00Z
Lists: pgsql-hackers
On Wed, Jun 7, 2023 at 5:12 PM Andres Freund <andres@anarazel.de> wrote:
> -1. For me separating the P_NEW path makes a lot of sense, but isn't 16
> material.  I don't agree that it's a problem to have heaprel as a parameter in
> a bunch of places that don't strictly need it today.

As I've said, this is primarily about keeping all of the branches
consistent. I agree that there is no particular known consequence to
not doing this, and have said as much several times.

> I don't really understand why the patch does s/heaprel/heapRel/.

That has been the style used within nbtree for many years now.

> Most of these
> functions aren't actually using camelcase parameters? This part of the change
> just blows up the size, making it harder to review.

I wonder what made it impossibly hard to review the first time around.
The nbtree aspects of this work were pretty much written on
auto-pilot. I had no intention of making a fuss about it, but then I
never expected this push back.

-- 
Peter Geoghegan



Commits

  1. nbtree: Allocate new pages in separate function.

  2. Pass down table relation into more index relation functions

  3. Note case where nbtree VACUUM finishes splits.

  4. Fix interaction between CREATE INDEX and "snapshot too old".