On 2017-11-28 09:47:45 +0900, Michael Paquier wrote: > On Mon, Nov 27, 2017 at 3:28 PM, Alexander Korotkov > <a.korot...@postgrespro.ru> wrote: > > Attached patch atomic-pgrename-windows-1.patch fixes this problem. It > > appears to be possible to atomically replace file on Windows – ReplaceFile() > > does that. ReplaceFiles() requires target file to exist, this is why we > > still need to call MoveFileEx() when it doesn't exist. > > Do you think that it could be safer to unlink the target file first > with pgunlink()? This way you make sure that the target file is > removed and not locked. This change makes me worrying about the > introduction of more race conditions.
That seems like a *seriously* bad idea. What if we crash inbetween the unlink and the rename? I'm confused about the need for this. Shouldn't normally opening all files FILE_SHARE_DELETE take care of this? See https://msdn.microsoft.com/en-us/library/windows/desktop/aa363858(v=vs.85).aspx "Note Delete access allows both delete and rename operations." Is there an external process active that doesn't set that flag? Are we missing setting it somewhere? Greetings, Andres Freund