| From: | Bryan Green <dbryan(dot)green(at)gmail(dot)com> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: [PATCH] Fix TOCTOU races in recovery/t/020_archive_status.pl archive checks |
| Date: | 2026-08-10 15:32:05 |
| Message-ID: | 7e301ccc-4a38-4eec-a09f-193b983abbe7@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2026-08-10 16:04:52 | preventing shell injection |
| Previous Message | Bryan Green | 2026-08-10 15:12:50 | Re: [PATCH] Make select_views regression test output deterministic |