Re: Add pg_buffercache_evict_all() and pg_buffercache_mark_dirty[_all]() functions - Mailing list pgsql-hackers

From Nazir Bilal Yavuz
Subject Re: Add pg_buffercache_evict_all() and pg_buffercache_mark_dirty[_all]() functions
Date
Msg-id CAN55FZ0eZ_hK4=Y-kS7sNd0tb9vovT5dAsyHRPryAGwjWuz+cg@mail.gmail.com
Whole thread Raw
In response to Re: Add pg_buffercache_evict_all() and pg_buffercache_mark_dirty[_all]() functions  (Nazir Bilal Yavuz <byavuz81@gmail.com>)
Responses Re: Add pg_buffercache_evict_all() and pg_buffercache_mark_dirty[_all]() functions
List 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 by date:

Previous
From: Alena Rybakina
Date:
Subject: Re: POC, WIP: OR-clause support for indexes
Next
From: vignesh C
Date:
Subject: Re: [18] CREATE SUBSCRIPTION ... SERVER