Re: Cleaning up nbtree after logical decoding on standby work

Michael Paquier <michael@paquier.xyz>

From: Michael Paquier <michael@paquier.xyz>
To: Peter Geoghegan <pg@bowt.ie>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, "Drouvot, Bertrand" <bertranddrouvot.pg@gmail.com>, Andres Freund <andres@anarazel.de>
Date: 2023-05-29T00:31:02Z
Lists: pgsql-hackers
On Fri, May 26, 2023 at 04:48:37PM -0700, Peter Geoghegan wrote:
> I'd have thought the subject line "Cleaning up nbtree after logical
> decoding on standby work" made it quite clear that this patch was
> targeting 16.

Hmm, okay.  I was understanding that as something for v17, honestly.

> It's not refactoring work -- not really. The whole idea of outright
> removing the use of P_NEW in nbtree was where I landed with this after
> a couple of hours of work. In fact I almost posted a version without
> that, though that was worse in every way to my final approach.
> 
> I first voiced concerns about this whole area way back on April 4,
> which is only 3 days after commit 61b313e4 went in:
> 
> https://postgr.es/m/CAH2-Wz=jGryxWm74G1khSt0zNPUNhezYJnvSjNo2t3Jswtb8ww@mail.gmail.com

Sure.  My take is that if this patch were to be sent at the beginning
of April, it could have been considered in v16.  However, deciding
such a matter at the end of May after beta1 has been released is a
different call.  You may want to make sure that the RMT is OK with
that, at the end.
--
Michael

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