From 9431cce4dc97fe3eaad73e6f98ac16d62755eb82 Mon Sep 17 00:00:00 2001 From: Fujii Masao Date: Thu, 3 Sep 2026 12:09:49 +0900 Subject: [PATCH] Stabilize recovery conflict stats checks in 031_recovery_conflict.pl The buildfarm member akepa reported a failure in the 031_recovery_conflict.pl test. The test checked pg_stat_database_conflicts immediately after detecting a recovery conflict in the standby log. However, the conflict counter is flushed by the canceled backend during backend exit, so WAL replay completion and the log message did not guarantee that the updated statistics are visible yet. So, previously, the test could see a conflict counter of 0 even though the conflict had already occurred, triggering the test failure. Fix this by polling for the expected conflict counter instead of reading it only once, handling the asynchronous pgstats update. Per buildfarm member akepa. Backpatch to v17, where this test is enabled and has the same race. Author: Fujii Masao Reviewed-by: Ayush Tiwari Reviewed-by: Nazir Bilal Yavuz Discussion: https://postgr.es/m/CAHGQGwHmiLNRfvJDAR=PmxQgf7DbzPSO1M-1RoqO8oy=t2G5KA@mail.gmail.com Backpatch-through: 17 --- src/test/recovery/t/031_recovery_conflict.pl | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/src/test/recovery/t/031_recovery_conflict.pl b/src/test/recovery/t/031_recovery_conflict.pl index 7a740f69806..c87acd20e0a 100644 --- a/src/test/recovery/t/031_recovery_conflict.pl +++ b/src/test/recovery/t/031_recovery_conflict.pl @@ -325,9 +325,10 @@ sub check_conflict_log sub check_conflict_stat { my $conflict_type = shift; - my $count = $node_standby->safe_psql($test_db, - qq[SELECT confl_$conflict_type FROM pg_stat_database_conflicts WHERE datname='$test_db';] - ); - is($count, 1, "$sect: stats show conflict on standby"); + ok( $node_standby->poll_query_until( + $test_db, + qq[SELECT confl_$conflict_type FROM pg_stat_database_conflicts WHERE datname='$test_db';], + '1'), + "$sect: stats show conflict on standby"); }