Hi, I investigated the 031_recovery_conflict.pl test failure reported by buildfarm member akepa [1], since it occurred just after the commit I pushed. But that seems unrelated to that commit.
[01:46:23.473](0.028s) not ok 12 - tablespace conflict: stats show
conflict on standby
[01:46:23.474](0.001s) # Failed test 'tablespace conflict: stats
show conflict on standby'
# at
/home/buildfarm/build-farm-21/buildroot/REL_19_STABLE/pgsql/src/test/recovery/t/031_recovery_conflict.pl
line 332.
[01:46:23.474](0.000s) # got: '0'
# expected: '1'
The test saw a recovery conflict counter of 0 when it expected 1.
Since the standby log contained the expected tablespace conflict
message, the conflict itself had already occurred. But, ISTM that
the counter in pg_stat_database_conflicts had not been updated yet
when the test checked it immediately afterward, causing the failure.
That is, there seems no guarantee that the conflict counter has been
flushed and become visible even after the conflict message has been
logged.
To fix this issue, I'd like to propose the attached patch that changes
the test to poll until the expected counter becomes visible instead of
checking it only once.
Thoughts?
Regards,
[1]
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=akepa&dt=2026-09-02%2005%3A43%3A06
--
Fujii Masao
v1-0001-Stabilize-recovery-conflict-stats-checks-in-031_r.patch
Description: Binary data
