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

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

  2. Support loading of injection points