Re: Add pg_buffercache_mark_dirty[_all] functions to the pg_buffercache - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Add pg_buffercache_mark_dirty[_all] functions to the pg_buffercache
Date
Msg-id aSeOmjq7viKaGM5H@paquier.xyz
Whole thread Raw
In response to Re: Add pg_buffercache_mark_dirty[_all] functions to the pg_buffercache  (Nazir Bilal Yavuz <byavuz81@gmail.com>)
Responses Re: Add pg_buffercache_mark_dirty[_all] functions to the pg_buffercache
Re: Add pg_buffercache_mark_dirty[_all] functions to the pg_buffercache
List 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

Attachment

pgsql-hackers by date:

Previous
From: Chao Li
Date:
Subject: Re: Consistently use palloc_object() and palloc_array()
Next
From: Michael Paquier
Date:
Subject: Re: Consistently use palloc_object() and palloc_array()