Re: Add pg_buffercache_mark_dirty[_all] functions to the pg_buffercache

From: Nazir Bilal Yavuz <byavuz81(at)gmail(dot)com>
To: Xuneng Zhou <xunengzhou(at)gmail(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Aidar Imamov <a(dot)imamov(at)postgrespro(dot)ru>, Joseph Koshakow <koshy44(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Add pg_buffercache_mark_dirty[_all] functions to the pg_buffercache
Date: 2025-04-28 09:12:50
Message-ID: CAN55FZ18YYPDRcFJ8HaqLb5tx3j=6ZGYWBQ7BqvOUrbG=bE6MA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On Fri, 25 Apr 2025 at 19:17, Xuneng Zhou <xunengzhou(at)gmail(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2025-04-28 09:20:02 Re: Fix premature xmin advancement during fast forward decoding
Previous Message Fujii Masao 2025-04-28 09:06:59 Re: Questions about logicalrep_worker_launch()