Re: Injection points: preloading and runtime arguments
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Heikki Linnakangas <hlinnaka@iki.fi>
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-10T04:16:15Z
Lists: pgsql-hackers
On Tue, Jul 09, 2024 at 12:08:26PM +0300, Heikki Linnakangas wrote: > And the injection point is attached in between the INJECTION_POINT_LOAD() > and INJECTION_POINT() calls, you will still get an assertion failure. For a > testing facility, maybe that's acceptable, but it could be fixed pretty > easily. > > I propose we introduce an INJECTION_POINT_CACHED(name) macro that *only* > uses the local cache. 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. > We could then also add an assertion in > InjectionPointRun() to check that it's not used in a critical section, to > enforce correct usage. That would be the same as what we do currently with a palloc() coming from load_external_function() or hash_create(), whichever comes first. Okay, the stack reported is deeper in this case. [1]: https://www.postgresql.org/message-id/87c748b3-0786-490f-a17a-51bef63e6c7f@iki.fi -- Michael
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