Re: Adding facility for injection points (or probe points?) for more advanced tests

Jeff Davis <pgsql@j-davis.com>

From: Jeff Davis <pgsql@j-davis.com>
To: Michael Paquier <michael@paquier.xyz>, Heikki Linnakangas <hlinnaka@iki.fi>
Cc: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>, Dilip Kumar <dilipbalaut@gmail.com>, Postgres hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-02-04T05:30:33Z
Lists: pgsql-hackers
On Tue, 2024-01-23 at 12:32 +0900, Michael Paquier wrote:
> Slightly off topic and while I don't forget about it..  Please find
> attached a copy of the patch posted around [1] to be able to define
> injection points with input arguments, so as it is possible to
> execute
> callbacks with values coming from the code path where the point is
> attached.
> 
> For example, a backend could use this kind of macro to have a
> callback
> attached to this point use some runtime value:
> INJECTION_POINT_1ARG("InjectionPointBoo", &some_value);

That sounds useful, but not necessarily required, for the HashAgg tests
I just posted[1].

One extra benefit of supporting arguments is that it would be a more
flexible way to change the local state around the injection point.
Right now the only way is by using IS_INJECTION_POINT_ATTACHED(), which
doesn't permit callback-defined conditions, etc.

If you do add suppport for arguments, would it make sense to just have
all callback functions take a single "void *" argument, rather than
adding branches for the zero-argument and the one-argument case?

+1 to the idea, but I'm fine waiting for additional use cases to get
the API right.

Regards,
	Jeff Davis

[1]
https://www.postgresql.org/message-id/ff4e59305e5d689e03cd256a736348d3e7958f8f.camel@j-davis.com




Commits

  1. ci: Enable injection points in builds

  2. Fix two memcpy() bugs in the new injection point code

  3. Add test module injection_points

  4. Add backend support for injection points

  5. Refactor code checking for file existence