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
