Re: Add pg_buffercache_mark_dirty[_all] functions to the pg_buffercache

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Add pg_buffercache_mark_dirty[_all] functions to the pg_buffercache
Дата
Msg-id aSeOmjq7viKaGM5H@paquier.xyz
обсуждение исходный текст
Ответ на Re: Add pg_buffercache_mark_dirty[_all] functions to the pg_buffercache  (Nazir Bilal Yavuz <byavuz81@gmail.com>)
Ответы Re: Add pg_buffercache_mark_dirty[_all] functions to the pg_buffercache
Re: Add pg_buffercache_mark_dirty[_all] functions to the pg_buffercache
Список pgsql-hackers
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

The approach looks acceptable here.  MarkDirtyUnpinnedBufferInternal()
is used as a workhorse to limit the duplication in the three routines
you are adding, and it is a slightly disappointing that the loops for
the buffers are duplicated, particularly for the relation vs the all
case, but we've also lived with these in core for the buffer eviction
and pg_buffercache.  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?
--
Michael

Вложения

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