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

From Amit Kapila
Subject Re: Add pg_buffercache_mark_dirty[_all] functions to the pg_buffercache
Date
Msg-id CAA4eK1KJV+b7xKVvQ-pCGMV7jd83KQp0SasdTJO9Lo5i-2t_sA@mail.gmail.com
Whole thread Raw
In response to Re: Add pg_buffercache_mark_dirty[_all] functions to the pg_buffercache  (Nazir Bilal Yavuz <byavuz81@gmail.com>)
List pgsql-hackers
On Mon, Apr 28, 2025 at 2:43 PM Nazir Bilal Yavuz <byavuz81@gmail.com> wrote:
>
> Hi,
>
> On Fri, 25 Apr 2025 at 19:17, Xuneng Zhou <xunengzhou@gmail.com> wrote:
> >
> >
> > Would love to hear if this makes sense or or am I overlooking something here. Thanks for any feedback!
>
> I think what you said makes sense and is correct if we only want to
> simulate a buffer’s dirty state for testing/debugging, but if we want
> to replicate usual steps to marking buffers as dirty, then I think we
> need to have full-page WAL writes.
>

Fair enough. But you haven't mentioned how exactly you want to use
these functions for testing? That will help us to understand whether
we need to replicate all the steps to mark the buffer dirty.

Also, I feel it will be easier for one to test the functionality by
marking buffers dirty for a particular relation rather than by using
buffer_id but maybe I am missing the testing scenarios you have in
mind for the proposed APIs.

The other point to consider was whether we need to lock the relation
for the proposed functions. If we already mark buffers dirty by
scanning the buffer pool in bgwriter/checkpointer without acquiring a
lock on the relation, then why do we need it here?

--
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Small fixes needed by high-availability tools
Next
From: Christoph Berg
Date:
Subject: libcurl in libpq.pc