Hi,
On Fri, 25 Apr 2025 at 19:17, Xuneng Zhou <xunengz...@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 just to 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
