database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2026-10-23 13:29:09 +03:00
Code Activity

Stabilize recovery conflict stats checks in 031_recovery_conflict.pl

Browse Source 
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 <masao.fujii@gmail.com>
Reviewed-by: Ayush Tiwari <ayushtiwari.slg01@gmail.com>
Reviewed-by: Nazir Bilal Yavuz <byavuz81@gmail.com>
Discussion: https://postgr.es/m/CAHGQGwHmiLNRfvJDAR=PmxQgf7DbzPSO1M-1RoqO8oy=t2G5KA@mail.gmail.com
Backpatch-through: 17
This commit is contained in:
Fujii Masao
2026-09-03 12:09:49 +09:00
parent b51dd2b2c5
commit 8254de34bc
1 changed files with 5 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

9
src/test/recovery/t/031_recovery_conflict.pl
View File

@@ -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");
}