Re: Add pg_buffercache_mark_dirty[_all] functions to the pg_buffercache
| От | Nazir Bilal Yavuz |
|---|---|
| Тема | Re: Add pg_buffercache_mark_dirty[_all] functions to the pg_buffercache |
| Дата | |
| Msg-id | CAN55FZ0AzMr=4bD+sgkTNh5xiWJAynJXtqXCSqmz3kuV0MuP7A@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Add pg_buffercache_mark_dirty[_all] functions to the pg_buffercache (邱宇航 <iamqyh@gmail.com>) |
| Ответы |
Re: Add pg_buffercache_mark_dirty[_all] functions to the pg_buffercache
|
| Список | 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 по дате отправления: