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

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

  1. Add INJECTION_POINT_CACHED() to run injection points directly from cache

  2. Support loading of injection points