Hi, On Wed, 2 Sept 2026 at 13:15, Fujii Masao <[email protected]> wrote:
> 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 Thanks for the patch. Polling for the exact expected value seems reasonable, since the conflict can be logged before the canceled backend's pending stats become visible. Patch lgtm. Regards, Ayush
