Re: MultiXact\SLRU buffers configuration
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: "Andrey M. Borodin" <x4mmm@yandex-team.ru>, vignesh C <vignesh21@gmail.com>, Andrew Borodin <amborodin86@gmail.com>, Yura Sokolov <y.sokolov@postgrespro.ru>, Andres Freund <andres@anarazel.de>, Thomas Munro <thomas.munro@gmail.com>, Gilles Darold <gilles@darold.net>, Alexander Korotkov <aekorotkov@gmail.com>, Daniel Gustafsson <daniel@yesql.se>, Kyotaro Horiguchi <horikyota.ntt@gmail.com>, pgsql-hackers mailing list <pgsql-hackers@postgresql.org>
Date: 2024-08-23T00:29:13Z
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
Commits
-
Rework new SLRU test with injection points
- 94a3373ac5c3 18.0 landed
-
injection_point: Add injection_points.stats
- 2e35c67f9568 18.0 landed
-
injection_points: Add initialization of shmem state when loading module
- b2b023aa3706 18.0 landed
-
Add injection-point test for new multixact CV usage
- 768a9fd5535f 18.0 landed
-
Use conditional variable to wait for next MultiXact offset
- a0e0fb1ba56f 17.0 landed
-
Improve performance of subsystems on top of SLRU
- 53c2a97a9266 17.0 landed
-
Adjust VACUUM hastup LP_REDIRECT comments.
- 325bc54eed4e 16.0 cited
-
Test replay of regression tests, attempt II.
- f47ed79cc8a0 15.0 cited