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 | CAN55FZ1BcYgs5f2HH81CRjdOxxfnuLZO5bbBUv4jC9evxLdDGg@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,
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 по дате отправления: