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 CAN55FZ0AzMr=4bD+sgkTNh5xiWJAynJXtqXCSqmz3kuV0MuP7A@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,

On Mon, 24 Nov 2025 at 11:47, 邱宇航 <iamqyh@gmail.com> wrote:
>
> > 2025年11月24日 15:50,Nazir Bilal Yavuz <byavuz81@gmail.com> 写道:
> >
> > 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?
>
> Bgwriter/Checkpointer might always blocks the mark buffer dirty SQL.
>
> sequence        Bgwriter/Checkpointer   mark-buffer-dirty SQL
> 1               LockBuffer(1)           WaitBuffer(1)
> 2               UnlockBuffer(1),
>                 and LockBuffer(2)
> 3                                       After unlock wakeup,
>                                         WaitBuffer(2)
> ...             ...                     ...
>
> I don't know if this could really happen. Maybe we need some tests. I
> just afraid that pg_buffercache_mark_dirty_{relation, all} SQL could be
> slow and inefficient.

I do not think that will be a problem but I can change it if the
general consensus is towards this way. Also, if we change this for
pg_buffercache_mark_dirty_* functions, I think we need to apply the
same for the pg_buffercache_evict_* functions.

--
Regards,
Nazir Bilal Yavuz
Microsoft



pgsql-hackers by date:

Previous
From: Dmitry Dolgov
Date:
Subject: Re: System views for versions reporting
Next
From: Filip Janus
Date:
Subject: Re: [PATCH] Better Performance for PostgreSQL with large INSERTs