aboutsummaryrefslogtreecommitdiff
path: root/doc/src
diff options
context:
space:
mode:
authorMichael Paquier <michael@paquier.xyz>2024-07-18 09:50:41 +0900
committerMichael Paquier <michael@paquier.xyz>2024-07-18 09:50:41 +0900
commita0a5869a8598cdeae1d2f2d632038d26dcc69d19 (patch)
treef8d31f1d376c1fc8bc26f434ba66e8de7ec2ee75 /doc/src
parent6159331acfbe2d08361947324e09e446138c7bc1 (diff)
downloadpostgresql-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.sgml17
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>