diff options
author | Michael Paquier <michael@paquier.xyz> | 2024-07-18 09:50:41 +0900 |
---|---|---|
committer | Michael Paquier <michael@paquier.xyz> | 2024-07-18 09:50:41 +0900 |
commit | a0a5869a8598cdeae1d2f2d632038d26dcc69d19 (patch) | |
tree | f8d31f1d376c1fc8bc26f434ba66e8de7ec2ee75 /doc/src | |
parent | 6159331acfbe2d08361947324e09e446138c7bc1 (diff) | |
download | postgresql-a0a5869a8598cdeae1d2f2d632038d26dcc69d19.tar.gz postgresql-a0a5869a8598cdeae1d2f2d632038d26dcc69d19.zip |
Add INJECTION_POINT_CACHED() to run injection points directly from cache
This new macro is able to perform a direct lookup from the local cache
of injection points (refreshed each time a point is loaded or run),
without touching the shared memory state of injection points at all.
This works in combination with INJECTION_POINT_LOAD(), and it is better
than INJECTION_POINT() in a critical section due to the fact that it
would avoid all memory allocations should a concurrent detach happen
since a LOAD(), as it retrieves a callback from the backend-private
memory.
The documentation is updated to describe in more details how to use this
new macro with a load. Some tests are added to the module
injection_points based on a new SQL function that acts as a wrapper of
INJECTION_POINT_CACHED().
Based on a suggestion from Heikki Linnakangas.
Author: Heikki Linnakangas, Michael Paquier
Discussion: https://postgr.es/m/58d588d0-e63f-432f-9181-bed29313dece@iki.fi
Diffstat (limited to 'doc/src')
-rw-r--r-- | doc/src/sgml/xfunc.sgml | 17 |
1 files changed, 10 insertions, 7 deletions
diff --git a/doc/src/sgml/xfunc.sgml b/doc/src/sgml/xfunc.sgml index 756a9d07fb0..7e92e898460 100644 --- a/doc/src/sgml/xfunc.sgml +++ b/doc/src/sgml/xfunc.sgml @@ -3619,17 +3619,20 @@ INJECTION_POINT(name); </para> <para> - An injection point with a given <literal>name</literal> can be loaded - using macro: + Executing an injection point can require allocating a small amount of + memory, which can fail. If you need to have an injection point in a + critical section where dynamic allocations are not allowed, you can use + a two-step approach with the following macros: <programlisting> INJECTION_POINT_LOAD(name); +INJECTION_POINT_CACHED(name); </programlisting> - This will load the injection point callback into the process cache, - doing all memory allocations at this stage without running the callback. - This is useful when an injection point is attached in a critical section - where no memory can be allocated: load the injection point outside the - critical section, then run it in the critical section. + Before entering the critical section, + call <function>INJECTION_POINT_LOAD</function>. It checks the shared + memory state, and loads the callback into backend-private memory if it is + active. Inside the critical section, use + <function>INJECTION_POINT_CACHED</function> to execute the callback. </para> <para> |