Re: Add pg_buffercache_evict_all() and pg_buffercache_mark_dirty[_all]() functions
От | Nazir Bilal Yavuz |
---|---|
Тема | Re: Add pg_buffercache_evict_all() and pg_buffercache_mark_dirty[_all]() functions |
Дата | |
Msg-id | CAN55FZ0eZ_hK4=Y-kS7sNd0tb9vovT5dAsyHRPryAGwjWuz+cg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Add pg_buffercache_evict_all() and pg_buffercache_mark_dirty[_all]() functions (Nazir Bilal Yavuz <byavuz81@gmail.com>) |
Ответы |
Re: Add pg_buffercache_evict_all() and pg_buffercache_mark_dirty[_all]() functions
|
Список | pgsql-hackers |
Hi, It seems that Aidar's email ended up as another thread [1]. I am copy-pasting mail and answer here to keep the discussion in this thread. On Sun, 23 Mar 2025 at 22:16, Aidar Imamov <a.imamov@postgrespro.ru> wrote: > > I agree with most of what Joseph said. However, I would like to add some > comments. > > At the moment, the "flushed" flag essentially indicates whether the > buffer > was dirty at the time of eviction and it does not guarantee that it has > been > written to disk. Therefore, it would be better to rename the > buffers_flushed > column in the output of pg_buffer_cache_evict_all() and > pg_buffercache_evict_relation() functions to dirty_buffers mb? This > would > allow us to avoid the confusion that arises from the fact that not all > dirty > buffers could have actually been written to disk. In addition, this > would > remove the "flushed" parameter from the EvictUnpinnedBuffer() function. > Because if we explicitly call LockBufHdr() outside of > EvictUnpinnedBuffer(), > we can already know in advance whether the buffer is dirty or not. > > The same applies to the suggestion to retrieve "flushed" count from the > pg_buffercache_evict() call. We cannot say this for certain, but we can > determine whether the buffer was dirty. I think flushed means 'passing the buffer contents to the kernel' in the Postgres context (as it is explained in the FlushBuffer()). We know that flush has happened, we just do not know if the buffer is flushed by us or someone else. [1] https://postgr.es/m/flat/76a550315baef9d7424b70144f1c6a2d%40postgrespro.ru -- Regards, Nazir Bilal Yavuz Microsoft
В списке pgsql-hackers по дате отправления: