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 | CAN55FZ32bsRUrcLoTWCApdmwaXrFVTovH07Pke-VCn=hBmtgzA@mail.gmail.com обсуждение исходный текст |
Ответ на | Add pg_buffercache_mark_dirty[_all] functions to the pg_buffercache (Nazir Bilal Yavuz <byavuz81@gmail.com>) |
Список | 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.kapila16@gmail.com> wrote: > > On Mon, Apr 28, 2025 at 2:43 PM Nazir Bilal Yavuz <byavuz81@gmail.com> wrote: > > > > Hi, > > > > On Fri, 25 Apr 2025 at 19:17, Xuneng Zhou <xunengzhou@gmail.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
Вложения
В списке pgsql-hackers по дате отправления: