Re: Add pg_buffercache_mark_dirty[_all] functions to the pg_buffercache - Mailing list pgsql-hackers

From Nazir Bilal Yavuz
Subject Re: Add pg_buffercache_mark_dirty[_all] functions to the pg_buffercache
Date
Msg-id CAN55FZ1BcYgs5f2HH81CRjdOxxfnuLZO5bbBUv4jC9evxLdDGg@mail.gmail.com
Whole thread Raw
In response to Re: Add pg_buffercache_mark_dirty[_all] functions to the pg_buffercache  (邱宇航 <iamqyh@gmail.com>)
Responses Re: Add pg_buffercache_mark_dirty[_all] functions to the pg_buffercache
List pgsql-hackers
Hi,

Thank you for looking into this!

On Mon, 24 Nov 2025 at 09:51, 邱宇航 <iamqyh@gmail.com> wrote:
>
> I suggest using a conditional lock on the buffer, which would be more
> appropriate here.

Could you please explain that a bit more? AFAIU, conditional locks are
mainly used to escape from deadlock situations and we can not cause a
deadlock here. Is it because using conditional locks might make the
functions faster by skipping the wait situations?

> Additionally, the function should return whether
> the buffer is marked as dirty, the number of buffers marked as dirty.
>
> This change would also make pg_buffercache_mark_dirty_{relation, all}
> behave more consistently with pg_buffercache_evict_{relation,all}.

Do you mean that we should not return 'buffer_already_dirty'
information and we should only return 'buffer_dirtied' information in
the 'pg_buffercache_mark_dirty' function? If you are suggesting that,
I think returning 'buffer_already_dirty' has a value in it.

> Lastly, `CHECK_FOR_INTERRUPTS()` should be added inside the loop over
> `NBuffers` to ensure it can be interrupted during long-running
> operations.

You are right, applied to v9 in the email below [1].

[1] https://postgr.es/m/CAN55FZ1E4ruwjjarUc0WoHxSpW%3DCZ0aEPfSrUC4z65UtEM7DNw%40mail.gmail.com

--
Regards,
Nazir Bilal Yavuz
Microsoft



pgsql-hackers by date:

Previous
From: Nazir Bilal Yavuz
Date:
Subject: Re: Add pg_buffercache_mark_dirty[_all] functions to the pg_buffercache
Next
From: Chao Li
Date:
Subject: Re: eliminate xl_heap_visible to reduce WAL (and eventually set VM on-access)