Re: Cleaning up nbtree after logical decoding on standby work

From: Andres Freund <andres(at)anarazel(dot)de>
To: Peter Geoghegan <pg(at)bowt(dot)ie>
Cc: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Michael Paquier <michael(at)paquier(dot)xyz>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, "Drouvot, Bertrand" <bertranddrouvot(dot)pg(at)gmail(dot)com>
Subject: Re: Cleaning up nbtree after logical decoding on standby work
Date: 2023-06-08 00:12:44
Message-ID: 20230608001244.7rlvnb6iru7hkfy7@awork3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2023-06-05 12:04:29 -0700, Peter Geoghegan wrote:
> On Sun, May 28, 2023 at 7:49 PM Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
> > IMO this makes sense for v16. These new arguments were introduced in
> > v16, so if we have second thoughts, now is the right time to change
> > them, before v16 is released. It will reduce the backpatching effort in
> > the future; if we apply this in v17, then v16 will be the odd one out.
>
> My current plan is to commit this later in the week, unless there are
> further objections. Wednesday or possibly Thursday.

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

I don't really understand why the patch does s/heaprel/heapRel/. 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.

12 files changed, 317 insertions(+), 297 deletions(-)
...

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tatsuo Ishii 2023-06-08 00:30:33 Re: Order changes in PG16 since ICU introduction
Previous Message Andres Freund 2023-06-07 23:47:26 Re: win32ver data in meson-built postgres.exe