Re: Add pg_buffercache_mark_dirty[_all] functions to the pg_buffercache

From: Nazir Bilal Yavuz <byavuz81(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Xuneng Zhou <xunengzhou(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Aidar Imamov <a(dot)imamov(at)postgrespro(dot)ru>, Joseph Koshakow <koshy44(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Add pg_buffercache_mark_dirty[_all] functions to the pg_buffercache
Date: 2025-11-28 08:27:11
Message-ID: CAN55FZ1A7MXuT64zBZhFfmHuQoHF_RSvYoeqOvXA-wdmyp+GXQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On Fri, 28 Nov 2025 at 03:36, Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> On Thu, Nov 27, 2025 at 10:59:47AM +0300, Nazir Bilal Yavuz wrote:
> > I agree with you, the patches make more sense this way.
> >
> > The patches are split into two in v10. There are no changes from v9,
> > except that one extra blank line was removed [1].
>
> Note that there were a couple of things incorrect in the docs. I have
> done a sweep to improve the wording in the comments and the docs
> themselves, then applied the result.

Thanks for doing this!

> Testing the valid case for the "_all" function flavor could be costly
> for installcheck so I am feeling a bit reserved on its cost. We are
> doing it for the evict case as well, so I have kept it at the end to
> keep the coverage. If it proves to be an issue or if there is a
> concern with this part, I would be OK to remove it.

You are right, I did not think of this aspect.

--
Regards,
Nazir Bilal Yavuz
Microsoft

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Chao Li 2025-11-28 08:34:51 Migrate to autoconf 2.72?
Previous Message Peter Eisentraut 2025-11-28 08:17:20 Re: Remove useless casting to the same type