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

From Nazir Bilal Yavuz
Subject Re: Add pg_buffercache_mark_dirty[_all] functions to the pg_buffercache
Date
Msg-id CAN55FZ18YYPDRcFJ8HaqLb5tx3j=6ZGYWBQ7BqvOUrbG=bE6MA@mail.gmail.com
Whole thread Raw
In response to Re: Add pg_buffercache_mark_dirty[_all] functions to the pg_buffercache  (Xuneng Zhou <xunengzhou@gmail.com>)
List pgsql-hackers
Hi,

On Fri, 25 Apr 2025 at 19:17, Xuneng Zhou <xunengzhou@gmail.com> wrote:
>
> Hi,
> I’ve been trying to review this patch, and it struck me that we’re currently grabbing the content lock exclusively
justto flip a header bit: 

Thank you for looking into this!

> if (!(buf_state & BM_DIRTY))
> {
>     LWLockAcquire(BufferDescriptorGetContentLock(desc), LW_EXCLUSIVE);
>     MarkBufferDirty(buf);
>     LWLockRelease(BufferDescriptorGetContentLock(desc));
> }
>
> Since our sole goal here is to simulate a buffer’s dirty state for testing/debugging, I wonder—could we instead:

I believe our goal is not only to simulate a buffer’s dirty state but
also replicating steps to mark the buffers as dirty.

> 1. Acquire the shared content lock (which already blocks eviction),
> 2. Call MarkBufferDirtyHint() to flip the BM_DIRTY bit under the header spinlock, and
> 3. Release the shared lock?
>
> This seems to satisfy Assert(LWLockHeldByMe(...)) inside the hint routine and would:
>
> - Prevent exclusive‐lock contention when sweeping many buffers,
> - Avoid full‐page WAL writes (we only need a hint record, if any)
>
>
> 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.

--
Regards,
Nazir Bilal Yavuz
Microsoft



pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: Questions about logicalrep_worker_launch()
Next
From: Amit Kapila
Date:
Subject: Re: Fix premature xmin advancement during fast forward decoding