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

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Adding facility for injection points (or probe points?) for more advanced tests
Date: 2025-02-05 00:19:22
Message-ID: Z6KuiuGybxflIDqH@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Smith 2025-02-05 00:23:19 Re: Avoid updating inactive_since for invalid replication slots
Previous Message Michael Paquier 2025-02-05 00:12:14 Re: [PATCH] Optionally record Plan IDs to track plan changes for a query