On Mon, Jan 22, 2024 at 10:47:17PM +0200, Heikki Linnakangas wrote:
> Michael, it was a pleasure to write this test with the injection points,
> compared to trying to set up PITR at just the right moment. Thank you! Since
> this is the first test that uses it, I didn't have any precedence to
> copy-paste; can you take a look and verify if this is how you imagined the
> facility to be used?
I was wondering how many weeks it would take for somebody to begin
playing with that, and here you are 12 hours later..
+EXTRA_INSTALL = src/test/modules/injection_points
[...]
+#ifdef USE_INJECTION_POINTS
+ if (GinPageIsLeaf(BufferGetPage(stack->buffer)))
+ INJECTION_POINT("gin-leave-leaf-split-incomplete");
+ else
+ INJECTION_POINT("gin-leave-internal-split-incomplete");
+#endif
Yes, that would be one way of doing it. It makes the code a bit more
invasive but that would work. Now, you expect this point to be
conditional depending on the state of the buffer. One thing I was
thinking of was to extend the APIs in injection_point.c to be able to
handle a set of arguments as a set of (void*) so as callbacks could
internally decide what they want to do depending on the running state.
I didn't have a use for it, but well, you do, so perhaps we could just
bite the bullet and do it.
That reduces the footprint on the backend code, moving more logic
behind USE_INJECTION_POINTS in injection_point.c. At the end, you
should be able to patch the core backend with something like that,
without using some ifdefs on USE_INJECTION_POINTS:
INJECTION_POINT_1ARG("gin-leave-leaf-split", (void *) buffer)
And INJECTION_POINT_1ARG() would be just a wrapper around something
like:
extern void InjectionPointRun1(const char *name, void *arg1);
And then plug in the callback you want. Having the callback in a new
test module with the SQL test itself would be OK, or you could just
add it to src/test/modules/injection_points/ with a SQL test in it, or
just use EXTRA_INSTALL.
--
Michael