Re: Cleaning up nbtree after logical decoding on standby work
От | Andres Freund |
---|---|
Тема | Re: Cleaning up nbtree after logical decoding on standby work |
Дата | |
Msg-id | 20230610044015.ahsu34i3vxaczw65@awork3.anarazel.de обсуждение исходный текст |
Ответ на | Re: Cleaning up nbtree after logical decoding on standby work (Peter Geoghegan <pg@bowt.ie>) |
Ответы |
Re: Cleaning up nbtree after logical decoding on standby work
|
Список | pgsql-hackers |
Hi, On 2023-06-09 12:23:36 -0700, Peter Geoghegan wrote: > On Fri, Jun 9, 2023 at 12:03 PM Andres Freund <andres@anarazel.de> wrote: > > > My new plan is to commit this tomorrow, since the clear consensus is > > > that we should go ahead with this for 16. > > > > I'm not sure there is that concensus (for me half the changes shouldn't be > > done, the rest should be in 17), but in the end it doesn't matter that much. > > Really? What parts are you opposed to in principle? I don't see why > you wouldn't support everything or nothing for 17 (questions of style > aside). I don't see what's ambiguous about what we should do here, > barring the 16-or-17 question. 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. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: