On 2017-11-28 09:47:45 +0900, Michael Paquier wrote:
> On Mon, Nov 27, 2017 at 3:28 PM, Alexander Korotkov
> <a.korotkov@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