Re: Cleaning up nbtree after logical decoding on standby work

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: Cleaning up nbtree after logical decoding on standby work
Дата
Msg-id CAH2-WzkOnfXTGx23oRgvzfYJCsybUrRgS4aRP09imwXUJyhd1A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Cleaning up nbtree after logical decoding on standby work  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Cleaning up nbtree after logical decoding on standby work
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Cleaning up threading code