Thanks for the v2 patch. I tested it locally and also instrumented XLogSendPhysical() to
verify the walsender behavior.
In the current test, both SendRqsPtr and sentPtr are 0/00D00000. Consequently, the walsender returnes at:
if (SendRqstPtr <= sentPtr) { WalSndCaughtUp = true; return; }
It never reaches WalSndSegmentOpen() and therefore does not attempt to open the WAL segment involved in the race.
I also reintroduced the old unlink() behavior. The file-existence assertion failed as expected, but the standby walsender still started successfully and did not report a missing WAL segment.
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.
