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

Michael Paquier <michael@paquier.xyz>

From: Michael Paquier <michael@paquier.xyz>
To: Jeff Davis <pgsql@j-davis.com>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>, Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>, Dilip Kumar <dilipbalaut@gmail.com>, Postgres hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-02-05T00:19:22Z
Lists: pgsql-hackers
On Mon, Feb 03, 2025 at 09:30:33PM -0800, Jeff Davis wrote:
> That sounds useful, but not necessarily required, for the HashAgg tests
> I just posted[1].

I thought so based on what you have posted on the other thread, as you
are relying on a three-step sequence to happen in a specific order,
multiple times.  A stack of repeated NOTICE messages is a bit noisy in
the output, still it should be enough.

> 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.

Agreed.  The line I'm drawing here (mentioned upthread as well) is
that any changes done in the core backend for injection_point.c should
have one or more use cases in the tree.

> 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?

Yep.  Just passing down a full structure would be enough with a single
argument. 

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

Thanks for the input and the comments.
--
Michael

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