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
0001-Use-injection_point-to-stabilize-035_standby_logical.patch
Description: 0001-Use-injection_point-to-stabilize-035_standby_logical.patch
