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