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>, Amit Kapila <amit(dot)kapila16(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-05-16 07:58:01
Message-ID: CABPTF7WANOf_e-Um8Yz7KaBYqWYQ2t-7Zvm0Jjwaj_kDrRVOEA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hey,

I noticed a couple of small clarity issues in the current version of patch
for potential clean up:

1. Commit message wording

Right now it says:

“The pg_buffercache_mark_dirty_all() function provides an efficient way to
dirty the entire buffer pool (e.g., ~550 ms vs. ~70 ms for 16 GB of shared
buffers), complementing pg_buffercache_mark_dirty() for more granular
control.”

That makes it sound like the *_all* function is the granular one, when
really:

• pg_buffercache_mark_dirty(buffernumber) is the fine-grained, per-buffer
call.

• pg_buffercache_mark_dirty_all() is the bulk, coarse-grained operation.

How about rephrasing to:

“The pg_buffercache_mark_dirty_all() function provides an efficient, bulk
way to mark every buffer dirty (e.g., ~70 ms vs. ~550 ms for 16 GB of
shared buffers), while pg_buffercache_mark_dirty() still allows per-buffer,
granular control.”

2. Inline comment in MarkUnpinnedBufferDirty

We currently have:

PinBuffer_Locked(desc); */* releases spinlock */*

Folks who’re unfamiliar with this function might get confused. Maybe we
could use the one in GetVictimBuffer:

*/* Pin the buffer and then release its spinlock */*

PinBuffer_Locked(buf_hdr);

That spelling-out makes it obvious what’s happening.

> 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.
>
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message jian he 2025-05-16 08:34:25 Re: Virtual generated columns
Previous Message Richard Guo 2025-05-16 07:26:01 Re: Virtual generated columns