Re: fsync with sync, and Win32 unlink
От | Claudio Natoli |
---|---|
Тема | Re: fsync with sync, and Win32 unlink |
Дата | |
Msg-id | A02DEC4D1073D611BAE8525405FCCE2B55F378@harris.memetrics.local обсуждение исходный текст |
Ответы |
Re: fsync with sync, and Win32 unlink
|
Список | pgsql-hackers-win32 |
Tom Lane wrote: > Claudio Natoli <claudio.natoli@memetrics.com> writes: > > Tom Lane wrote: > >> However, I don't see exactly how that can win? > > > Why not? > > More like "why?". The problem we have is with making sure that existing > files we don't want anymore will go away in a timely fashion. I don't > see how it helps to modify file creation to allow overwrite. We are not > (in most deletion cases) expecting anyone to re-create that file later. > > [snip] > > So unless I'm totally misunderstanding where you mean to use > this code, I don't see the point. I think you might be. I'm not suggesting that we modify file creation to allow overwrite. The suggestion is that we modify file creation to allow delete. Win32 _open() call opens files in a manner that does not allow them to be deleted when held by another process. However, "replacing" the open() call with an orchestrated call to CreateFile/_open_osfhandle appears to give us exactly that behaviour we expect from open() under *nix (specifically, being able to unlink a file held by another process). Am we talking at cross-purposes here? Cheers, Claudio --- Certain disclaimers and policies apply to all email sent from Memetrics. For the full text of these disclaimers and policies see <a href="http://www.memetrics.com/emailpolicy.html">http://www.memetrics.com/em ailpolicy.html</a>
В списке pgsql-hackers-win32 по дате отправления: