Re: Add pg_buffercache_mark_dirty[_all] functions to the pg_buffercache

From: Xuneng Zhou <xunengzhou(at)gmail(dot)com>
To: Nazir Bilal Yavuz <byavuz81(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-25 16:17:31
Message-ID: CABPTF7WJzD44s6808HcAE5sH1rrUw4J=2JnS5Z0+1HzD58gvRw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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:

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:

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!

Cheers,
Xuneng

Nazir Bilal Yavuz <byavuz81(at)gmail(dot)com> 于2025年4月11日周五 17:14写道:

> Hi,
>
> There is another thread [1] to add both pg_buffercache_evict_[relation
> | all] and pg_buffercache_mark_dirty[_all] functions to the
> pg_buffercache. I decided to create another thread as
> pg_buffercache_evict_[relation | all] functions are committed but
> pg_buffercache_mark_dirty[_all] functions still need review.
>
> pg_buffercache_mark_dirty(): This function takes a buffer id as an
> argument and tries to mark this buffer as dirty. Returns true on
> success.
> pg_buffercache_mark_dirty_all(): This is very similar to the
> pg_buffercache_mark_dirty() function. The difference is
> pg_buffercache_mark_dirty_all() does not take an argument. Instead it
> just loops over the shared buffers and tries to mark all of them as
> dirty. It returns the number of buffers marked as dirty.
>
> Since that patch is targeted for the PG 19, pg_buffercache is bumped to
> v1.7.
>
> Latest version is attached and people who already reviewed the patches are
> CCed.
>
> [1]
> postgr.es/m/CAN55FZ0h_YoSqqutxV6DES1RW8ig6wcA8CR9rJk358YRMxZFmw%40mail.gmail.com
>
> --
> Regards,
> Nazir Bilal Yavuz
> Microsoft
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2025-04-25 16:26:40 Re: Fix slot synchronization with two_phase decoding enabled
Previous Message Fujii Masao 2025-04-25 16:09:58 Questions about logicalrep_worker_launch()