Re: [PATCH] Fix TOCTOU races in recovery/t/020_archive_status.pl archive checks - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: [PATCH] Fix TOCTOU races in recovery/t/020_archive_status.pl archive checks
Date
Msg-id anpizO0VLptyOS_e@paquier.xyz
Whole thread
Responses Re: [(known) BUG] DELETE/UPDATE more than one row in partitioned foreign table
List pgsql-hackers
On Mon, Aug 10, 2026 at 10:32:05AM -0500, Bryan Green wrote:
> 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.

This one depends on the community buildfarm for me, and it looks like
I have lost access to the buildfarm database..  Adding Alexander
Lakhin in CC, perhaps he has bumped into a failure on this one.

I miss the highlights in the CI, now I have not seen this test show up
recently there.

@Alexander: Have you noticed some turbulence in the force regarding
the recovery test 020_archive_status.pl?
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Peter Smith
Date:
Subject: Re: Missing list_free in publicationcmds.c:OpenTableList
Next
From: Masahiko Sawada
Date:
Subject: Re: Why is the LSN reported for pg_logical_emit_message() different from other decoded operations?