RE: Fix 035_standby_logical_decoding.pl race conditions

Dear Amit, Bertrand,

> Seeing all these failures, I wonder whether we can reliably test
> active slots apart from wal_level change test (aka Scenario 6:
> incorrect wal_level on primary.). Sure, we can try by having some
> injection point kind of tests, but is it really worth because, anyway
> the active slots won't get invalidated in the scenarios for row
> removal we are testing in this case. The other possibility is to add a
> developer-level debug_disable_running_xact GUC to test this and
> similar cases, or can't we have an injection point to control logging
> this WAL record? I have seen the need to control logging running_xact
> record in other cases as well.

Based on the idea which controls generating RUNNING_XACTS, I prototyped a patch.
When the instance is attached the new injection point, all processes would skip
logging the record. This does not need to extend injection_point module.
I tested with reproducer and passed on my env.
Sadly IS_INJECTION_POINT_ATTACHED() was introduced for PG18 so that the patch
could not backport for PG17 as-is.

How do you feel?

Best regards,
Hayato Kuroda
FUJITSU LIMITED