Re: [PATCH] Atomic pgrename on Windows
От | Andres Freund |
---|---|
Тема | Re: [PATCH] Atomic pgrename on Windows |
Дата | |
Msg-id | 20171128005901.g6ktibivyy4uaqxk@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: [PATCH] Atomic pgrename on Windows (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: [PATCH] Atomic pgrename on Windows
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: