Re: Add pg_buffercache_mark_dirty[_all] functions to the pg_buffercache
| От | 邱宇航 |
|---|---|
| Тема | Re: Add pg_buffercache_mark_dirty[_all] functions to the pg_buffercache |
| Дата | |
| Msg-id | C13D309F-9B3B-4057-BC55-2F845056CA7E@gmail.com обсуждение исходный текст |
| Ответ на | Re: Add pg_buffercache_mark_dirty[_all] functions to the pg_buffercache (Michael Paquier <michael@paquier.xyz>) |
| Ответы |
Re: Add pg_buffercache_mark_dirty[_all] functions to the pg_buffercache
|
| Список | pgsql-hackers |
> It is a slightly disappointing that the loops for > the buffers are duplicated, particularly for the relation vs the all > case. Yes, and we got another two loops in pg_buffercache_evict functions, and more loops in Drop/Flush relation/database buffers functions. Maybe we can abstract them into a generic loop function and it takes a buffer handler function pointer to avoid duplication? > One thing that would make more sense to me is to > split the patch in two: one for the changes in bufmgr.c/h and one for > pg_buffercache. There can be an argument that these new APIs could be > useful for out-of-core code, as well, to let developers play with the > state of the buffers. I mean, why not, the thread is also about API > extensibility, as well, to enforce dirty states. :) Agreed. It might be three, one for generic loop function, one for API and one for pg_buffercache. If we put new API out-of-core, the latter two can be merged. Best regards, Yuhang Qiu
В списке pgsql-hackers по дате отправления: