Re: Injection points: preloading and runtime arguments
Heikki Linnakangas <hlinnaka@iki.fi>
From: Heikki Linnakangas <hlinnaka@iki.fi>
To: Michael Paquier <michael@paquier.xyz>
Cc: "Andrey M. Borodin" <x4mmm@yandex-team.ru>,
Alvaro Herrera <alvherre@alvh.no-ip.org>,
Postgres hackers <pgsql-hackers@lists.postgresql.org>
Date: 2024-07-16T08:20:57Z
Lists: pgsql-hackers
Attachments
- v2-0001-Add-INJECTION_POINT_CACHED.patch (text/x-patch) patch v2-0001
- v2-0002-rephrase-docs-paragraph.patch (text/x-patch) patch v2-0002
On 16/07/2024 07:09, Michael Paquier wrote: > On Wed, Jul 10, 2024 at 01:16:15PM +0900, Michael Paquier wrote: >> You mean with something that does a injection_point_cache_get() >> followed by a callback run if anything is found in the local cache? >> Why not. Based on what you have posted at [1], it looks like this had >> better check the contents of the cache's generation with what's in >> shmem, as well as destroying InjectionPointCache if there is nothing >> else, so there's a possible dependency here depending on how much >> maintenance this should do with the cache to keep it consistent. > > Now that 86db52a5062a is in the tree, this could be done with a > shortcut in InjectionPointCacheRefresh(). What do you think about > something like the attached, with your suggested naming? Yes, +1 for something like that. The "direct" argument to InjectionPointCacheRefresh() feels a bit weird. Also weird that it still checks ActiveInjectionPoints->max_inuse, even though it otherwise operates on the cached version only. I think you can just call injection_point_cache_get() directly from InjectionPointCached(), per attached. I also rephrased the docs section a bit, focusing more on why and how you use the LOAD/CACHED pair, and less on the mechanics of how it works. -- Heikki Linnakangas Neon (https://neon.tech)
Commits
-
Add INJECTION_POINT_CACHED() to run injection points directly from cache
- a0a5869a8598 18.0 landed
-
Support loading of injection points
- 4b211003ecc2 18.0 landed