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
signature.asc
Description: PGP signature
