Re: Cleaning up nbtree after logical decoding on standby work - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: Cleaning up nbtree after logical decoding on standby work
Date
Msg-id CAH2-WzkX-RAhGbkzgLLxCeOGtb1_Fr-GeSr=ijdnHC1Gb2SF+Q@mail.gmail.com
Whole thread Raw
In response to Re: Cleaning up nbtree after logical decoding on standby work  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Cleaning up nbtree after logical decoding on standby work
List pgsql-hackers
On Fri, May 26, 2023 at 4:05 PM Michael Paquier <michael@paquier.xyz> wrote:
> On Fri, May 26, 2023 at 10:56:53AM +0200, Alvaro Herrera wrote:
> > I can't make up my mind about this.  What do others think?
>
> When I looked at the patch yesterday, my impression was that this
> would be material for v17 as it is refactoring work, not v16.

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.

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

--
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Jeff Davis
Date:
Subject: Fix search_path for all maintenance commands
Next
From: vignesh C
Date:
Subject: Re: Implement generalized sub routine find_in_log for tap test