Re: MultiXact\SLRU buffers configuration

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: "Andrey M(dot) Borodin" <x4mmm(at)yandex-team(dot)ru>, vignesh C <vignesh21(at)gmail(dot)com>, Andrew Borodin <amborodin86(at)gmail(dot)com>, Yura Sokolov <y(dot)sokolov(at)postgrespro(dot)ru>, Andres Freund <andres(at)anarazel(dot)de>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Gilles Darold <gilles(at)darold(dot)net>, Alexander Korotkov <aekorotkov(at)gmail(dot)com>, Daniel Gustafsson <daniel(at)yesql(dot)se>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, pgsql-hackers mailing list <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: MultiXact\SLRU buffers configuration
Date: 2024-08-23 00:29:13
Message-ID: ZsfX2ZcipxzMehSE@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Aug 22, 2024 at 10:36:38AM -0400, Alvaro Herrera wrote:
> On 2024-Aug-22, Michael Paquier wrote:
>> I'm not sure that we need to get down to that until somebody has a
>> case where they want to rely on stats of injection points for their
>> stuff. At this stage, I only want the stats to be enabled to provide
>> automated checks for the custom pgstats APIs, so disabling it by
>> default and enabling it only in the stats test of the module
>> injection_points sounds kind of enough to me for now.
>
> Oh! I thought the stats were useful by themselves.

Yep, currently they're not, but I don't want to discard that they'll
never be, either. Perhaps there would be a case where somebody would
like to run a callback N times and trigger a condition? That's
something where the stats could be useful, but I don't have a specific
case for that now. I'm just imagining possibilities.

> That not being the case, I agree with simplifying; and the other
> ways to enhance this point might not be necessary for now.

Okay.

>> Sticking some knowledge about the stats in the backend part of
>> injection points does not sound like a good idea to me.
>
> You could flip this around: have the bool be for "this injection point
> is going to be invoked inside a critical section". Then core code just
> needs to tell the injection points module what core code does, and it's
> injection_points that decides what to do with that information.

Hmm. We could do that, but I'm not really on board with anything that
adds more code footprint into the backend. For this one, this is even
information specific to the code path where the injection point is
added.
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Korotkov 2024-08-23 00:56:23 Re: Add SPLIT PARTITION/MERGE PARTITIONS commands
Previous Message Michael Paquier 2024-08-23 00:22:22 Re: Improving the notation for ecpg.addons rules