Dear Michael,
> Yes. The function could be changed to return an ERROR if the build
> does not support this option. It's more portable to return NULL if
> you have some queries that do joins. This could be used with
> pg_stat_activity and wait events for example, and some points are in
> positions strategic enough that they could be used across more than
> one library, like the restart point one or the autovacuum startup one.
Thanks for the description. +1.
> > I'm not sure it is directly related, but ISTM there are no direct ways to check
> > whether the injection_points is enabled or not. How do you think adding the
> > function?
>
> Yeah, we could use something like that, not sure if that's worth it.
We can fork new thread when it is required...
> > Regarding the internal of the patch, it could be crashed when two points are
> > attached and then first one is detached [1]. I think we should not use "idx" for
> > the result array - PSA the fix.
>
> Oops. That's a brain fart from my side. Thanks.
Confirmed v2 could fix the issue. One minor comment related with my part:
Should cur_pos be uint32 instead of int? Either of them can work because
cur_pos can be [0, 128], but it may be clearer.
Apart from above, LGTM.
Best regards,
Hayato Kuroda
FUJITSU LIMITED
