On 8/10/26 03:25, Michael Paquier wrote: > On Sat, Aug 08, 2026 at 10:47:26PM -0500, Bryan Green wrote: >> recovery/t/020_archive_status.pl checks archiving progress in two separate >> queries: it polls pg_stat_archiver for one condition, then asserts a related >> one. For the primary it polls until archived_count is exactly 1, then >> separately asserts last_archived_wal equals a specific segment; for the >> always-on standby it polls until last_archived_wal equals a segment, then >> asserts archived_count is exactly 2. >> >> Both are racy. A checkpoint or crash-recovery segment archived between the >> two queries pushes the count or last_archived_wal past the exact value >> expected. The exact-equality poll is fragile on its own, too: if the count >> jumps past the target, the poll never sees it and times out. >> >> The fix uses monotonic >= instead of exact equality, so the checks tolerate >> extra archived segments. WAL segment names sort lexically, so >= is >> well defined for last_archived_wal. > > This test has been around for some time now. Do we have noise in the > buildfarm or in the CI related to it because of extra segments > generated that make these queries fail? No.
> > Note: I don't really object to lift these three conditions to comply > more with potential concurrent activity. Just wondering how relevant > this is in practice, particularly when it comes to slow-ish > environments. Or perhaps you have played with this test in a fork? I have been playing in this area with a fork, and looking at it more closely, this doesn't fix a stock failure. To correct my original note-- a plain CHECKPOINT doesn't force a segment switch, so that wasn't a real trigger either. The change just trades a little coverage (exact-equality would catch a spurious extra segment; >= wouldn't) for tolerance of concurrent archiving that only happens in the fork. I don't have an upstream case for it and I'm happy to drop it. If you think the added tolerance is worth keeping as hygiene, I'll leave that to you. -- Bryan Green EDB: https://www.enterprisedb.com
