public inbox for [email protected]
help / color / mirror / Atom feedFrom: Michael Paquier <[email protected]>
To: Alvaro Herrera <[email protected]>
Cc: Andrey M. Borodin <[email protected]>
Cc: vignesh C <[email protected]>
Cc: Andrew Borodin <[email protected]>
Cc: Yura Sokolov <[email protected]>
Cc: Andres Freund <[email protected]>
Cc: Thomas Munro <[email protected]>
Cc: Gilles Darold <[email protected]>
Cc: Alexander Korotkov <[email protected]>
Cc: Daniel Gustafsson <[email protected]>
Cc: Kyotaro Horiguchi <[email protected]>
Cc: pgsql-hackers mailing list <[email protected]>
Subject: Re: MultiXact\SLRU buffers configuration
Date: Fri, 23 Aug 2024 09:29:13 +0900
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
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
Attachments:
[application/pgp-signature] signature.asc (833B, ../[email protected]/2-signature.asc)
download
view thread (10+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: MultiXact\SLRU buffers configuration
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox