From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
Cc: | "Andrey M(dot) Borodin" <x4mmm(at)yandex-team(dot)ru>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Injection points: preloading and runtime arguments |
Date: | 2024-07-10 04:16:15 |
Message-ID: | Zo4LD044_H9aSLqQ@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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
From | Date | Subject | |
---|---|---|---|
Next Message | jian he | 2024-07-10 04:25:56 | Re: array_in sub function ReadArrayDimensions error message |
Previous Message | Peter Smith | 2024-07-10 04:03:44 | Re: Logical Replication of sequences |