Re: Injection points: preloading and runtime arguments - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Injection points: preloading and runtime arguments
Date
Msg-id Zo4LD044_H9aSLqQ@paquier.xyz
Whole thread Raw
In response to Re: Injection points: preloading and runtime arguments  (Heikki Linnakangas <hlinnaka@iki.fi>)
Responses Re: Injection points: preloading and runtime arguments
List 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

Attachment

pgsql-hackers by date:

Previous
From: Peter Smith
Date:
Subject: Re: Logical Replication of sequences
Next
From: jian he
Date:
Subject: Re: array_in sub function ReadArrayDimensions error message