On Tue, Jan 27, 2026 at 5:37 PM Andres Freund <[email protected]> wrote: > On 2026-01-28 05:16:13 +1300, Thomas Munro wrote: > > But I wonder if you can't rename("old", "new") where "new" is a file that > > has already been unlinked (or renamed over) that someone still holds open, > > or something like that... > > I don't see a source of that that would be specific to this test though :(. We > do wait for pg_basebackup to have shut down, which wrote backup.label (which > was "manifactured" during streaming by basebackup.c).
I have no specific ideas, but just in case it's helpful for this discussion, I looked at my old test suite[1] where I tried to catalogue all the edge conditions around this sort of stuff empirically, and saw that rename() always fails like that if the file is open (that is, it doesn't require a more complicated sequence with an earlier unlink/rename of the new name): + /* + * Windows can't rename over an open non-unlinked file, even with + * have_posix_unlink_semantics. + */ + pgwin32_dirmod_loops = 2; /* minimize looping to fail fast in testing */ + PG_EXPECT_SYS(rename(path, path2) == -1, + "Windows: can't rename name1.txt -> name2.txt while name2.txt is open"); + PG_EXPECT_EQ(errno, EACCES); [1] https://www.postgresql.org/message-id/flat/CA%2BhUKG%2BajSQ_8eu2AogTncOnZ5me2D-Cn66iN_-wZnRjLN%2Bicg%40mail.gmail.com
