Re: Add pg_buffercache_mark_dirty[_all] functions to the pg_buffercache

From: Nazir Bilal Yavuz <byavuz81(at)gmail(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Xuneng Zhou <xunengzhou(at)gmail(dot)com>, 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-08-08 10:16:57
Message-ID: CAN55FZ32bsRUrcLoTWCApdmwaXrFVTovH07Pke-VCn=hBmtgzA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

Thank you for looking into this! And sorry for the late reply.

On Mon, 12 May 2025 at 13:24, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Mon, Apr 28, 2025 at 2:43 PM Nazir Bilal Yavuz <byavuz81(at)gmail(dot)com> wrote:
> >
> > Hi,
> >
> > On Fri, 25 Apr 2025 at 19:17, Xuneng Zhou <xunengzhou(at)gmail(dot)com> wrote:
> > >
> > >
> > > 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.
> >
>
> Fair enough. But you haven't mentioned how exactly you want to use
> these functions for testing? That will help us to understand whether
> we need to replicate all the steps to mark the buffer dirty.

Sorry, you are right. Main idea of this change is to test WAL writes
on CHECKPOINT, I think MarkBufferDirtyHint() is enough for this
purpose but I was thinking about someone else might want to use this
function and I think they expect to replicate all steps to mark the
buffer dirty.

> Also, I feel it will be easier for one to test the functionality by
> marking buffers dirty for a particular relation rather than by using
> buffer_id but maybe I am missing the testing scenarios you have in
> mind for the proposed APIs.

This is done in the v8.

> The other point to consider was whether we need to lock the relation
> for the proposed functions. If we already mark buffers dirty by
> scanning the buffer pool in bgwriter/checkpointer without acquiring a
> lock on the relation, then why do we need it here?

Sorry, I couldn't find this code part. Could you please elaborate more?

I updated patch a bit more, summary is:

- pg_buffercache_mark_dirty_relation() is added in v8.

- Function call is very similar to pg_buffercache_evict*(), we have
MarkDirtyUnpinnedBufferInternal() function inside bufmgr.c file and
this function is called from other functions.

-
pg_buffercache_mark_dirty() returns -> buffer_dirtied and
buffer_already_dirty as a boolean
pg_buffercache_mark_dirty_relation() returns -> buffers_dirtied,
buffers_already_dirty and buffers_skipped
pg_buffercache_mark_dirty_all() returns -> buffers_dirtied,
buffers_already_dirty and buffers_skipped

- Commit message and docs are updated regarding the changes above.

v8 is attached.

--
Regards,
Nazir Bilal Yavuz
Microsoft

Attachment Content-Type Size
v8-0001-Add-pg_buffercache_mark_dirty-_relation-_all-func.patch text/x-patch 26.4 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Nazir Bilal Yavuz 2025-08-08 10:17:45 Re: Add pg_buffercache_mark_dirty[_all] functions to the pg_buffercache
Previous Message Álvaro Herrera 2025-08-08 09:54:59 Re: New commitfest app release on August 19th