Re: Fix archive restore race that could unlink WAL before rename

On Wed, Aug 05, 2026 at 10:46:25AM +0800, Neil Chen wrote:
> Therefore, the test does verify that the segment remains present before the
> rename, but the walsender portion does not currently exercise the
> reported race. It may be better either to remove that portion or arrange
> for SendRqstPtr > sentPtr so the walsender actually attempts to read the
> segment.

The test goes to great lengths to prove a point that can be guessed
directly by reading the code, and is enforced in the code:
durable_rename() ensures that we have no window once the unlink() is
gone.

IMO, there is no point in including the test at all; the position of
INJECTION_POINT() just serves at validating what durable_rename() is
designed to do: make a rename() atomic and offer durability
guarantees. I also suspect that the restore_command of the test is
going to break more than one buildfarm member.

One thing that may be worth adding is a mention that we care about
concurrent WAL senders, and that the race is still not closed on
Windows, though.

Spoiler: I don't care much about the WIN32 case but one could look at
something like ReplaceFile() if interested, as one idea? Just closing
the race on non-WIN32 has a good amount of value, and could always be
solved later. I have not looked if it's actually safe on the Postgres
side due to the handle requirements we have with share mode, just
throwing an idea.
--
Michael