From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Cc: | Andres Freund <andres(at)anarazel(dot)de> |
Subject: | Support for runtime parameters in injection points, for AIO tests |
Date: | 2025-04-14 07:46:22 |
Message-ID: | Z_y9TtnXubvYAApS@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi all,
(Andres in CC.)
While reading the AIO code I have noticed that the way it uses
injection points is limited by the fact that we don't have support for
runtime parameters in the existing injection point facility. The code
is shaped with two set/get functions that set a static parameter that
the injection callback would reuse internally, using
pgaio_inj_io_get(), and pgaio_io_call_inj() and a static
pgaio_inj_cur_handle. Relying on a static variable for that is not a
good idea, IMO, even if the stack is reset with a TRY/CATCH block on
error in the callback run.
Supporting runtime parameters in injection points is something that I
have mentioned as wanted a couple of times, but I was waiting for an
actual use-case in core before adding support for it, as mentioned
around here:
https://www.postgresql.org/message-id/Z_yN_gaLw-pE2ul-@paquier.xyz
test_aio is bringing one.
We are still in early April, and I'd like to propose a cleanup of the
AIO code on HEAD, even if we are post-feature freeze, to not release
this new code in this state, implying an open item. Please note that
I'm OK to take responsibility for this patch set at the end, reviews
are welcome.
Anyway, I have spent some time with my mind on that, and finished
with the attached patch set:
- 0001 is the addition of runtime parameters in the backend code. I
have made the choice of extending the existing INJECTION_POINT() and
INJECTION_POINT_CACHED() instead of introducing new macros. That's a
matter of taste, perhaps, but increasing the number of these macros
leads to a confusing result. This one is more invasive, but that's OK
for me. The code is shaped so as we can rely on
InjectionPointCallback to define the shape of a callback. It is
possible to pass down a full structure if one wants, that the callback
is then responsible for translating back. The AIO code only want an
AIO handle, which is simple.
- 0002 introduces a few updates to the module injection_points, adding
support for runtime parameters and some tests.
- 0003 cleans up the AOI test code, relying on 0001.
The CI is passing. Thoughts and comments are welcome.
--
Michael
Attachment | Content-Type | Size |
---|---|---|
0001-Add-support-for-runtime-arguments-in-injection-point.patch | text/x-diff | 19.2 KB |
0002-injection_points-Add-support-for-runtime-arguments.patch | text/x-diff | 9.9 KB |
0003-aio-Use-runtime-arguments-with-injections-points.patch | text/x-diff | 6.4 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2025-04-14 07:51:44 | Re: Adding facility for injection points (or probe points?) for more advanced tests |
Previous Message | David Rowley | 2025-04-14 07:39:51 | Fixup some appendPQExpBuffer() calls |