Re: Cleaning up nbtree after logical decoding on standby work

On Fri, Jun 9, 2023 at 9:40 PM Andres Freund <andres@anarazel.de> wrote:
> I don't think minimizing heaprel being passed around is a worthwhile goal, the
> contrary actually: It just makes it painful to use heaprel anywhere, because
> it causes precisely these cascading changes of adding/removing the parameter
> to a bunch of functions. If anything we should do the opposite.
>
>
> > It's not like nbtree ever really "used P_NEW". It doesn't actually
> > depend on any of the P_NEW handling inside bufmgr.c. It looks a little
> > like it might, but that's just an accident.
>
> That part I am entirely on board with, as mentioned earlier. It doesn't seem
> like 16 material though.

Obviously you shouldn't need a heaprel to lock a page. As it happened
GiST already worked without this sort of P_NEW idiom, which is why
commit 61b313e4 hardly made any changes at all to GiST, even though
the relevant parts of GiST are heavily based on nbtree. Did you just
forget to plaster similar heaprel arguments all over GiST and SP-GiST?

I'm really disappointed that you're still pushing back here, even
after I got a +1 on backpatching from Heikki. This should have been
straightforward.

-- 
Peter Geoghegan