Re: [PATCH] Fix TOCTOU races in recovery/t/020_archive_status.pl archive checks

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?

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?
--
Michael