Re: Add pg_buffercache_mark_dirty[_all] functions to the pg_buffercache

Поиск
Список
Период
Сортировка
От Nazir Bilal Yavuz
Тема Re: Add pg_buffercache_mark_dirty[_all] functions to the pg_buffercache
Дата
Msg-id CAN55FZ0DWe5X-mVMoQVez4z4+iM7=JUPW9XxayrN-fkg4SgtAQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Add pg_buffercache_mark_dirty[_all] functions to the pg_buffercache  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: Add pg_buffercache_mark_dirty[_all] functions to the pg_buffercache
Список pgsql-hackers
Hi,

On Thu, 27 Nov 2025 at 02:35, Michael Paquier <michael@paquier.xyz> wrote:
>
> On Mon, Nov 24, 2025 at 10:48:24AM +0300, Nazir Bilal Yavuz wrote:
> > Thanks for the heads up! It is rebased, I also added
> > 'CHECK_FOR_INTERRUPTS()' while looping over the 'NBuffers' regarding
> > the comment in the email [1].
> >
> > [1] https://postgr.es/m/D5BB1D85-0F2A-419F-A7B1-426505525D3A%40gmail.com
>
> One thing that would make more sense to me is to
> split the patch in two: one for the changes in bufmgr.c/h and one for
> pg_buffercache.  There can be an argument that these new APIs could be
> useful for out-of-core code, as well, to let developers play with the
> state of the buffers.  I mean, why not, the thread is also about API
> extensibility, as well, to enforce dirty states.  :)
>
> Any thoughts or comments from others?

I agree with you, the patches make more sense this way.

The patches are split into two in v10. There are no changes from v9,
except that one extra blank line was removed [1].

[1] https://postgr.es/m/188562F6-5BBB-49AB-B9E1-6312AE7970E8%40gmail.com

-- 
Regards,
Nazir Bilal Yavuz
Microsoft

Вложения

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