Обсуждение: Re: fsync with sync, and Win32 unlink

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>

Claudio Natoli <claudio.natoli@memetrics.com> writes:
> Tom Lane wrote:
>> 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).

Hmm ... so you're suggesting that if every open() that can ever open a
Postgres file is replaced by this win32_open() code, then unlink()ing
the file will behave as per Unix custom?  Presumably, if we miss even
one open(), or some random admin is more'ing a file when we try to
delete it, the database crashes?

This strikes me as pretty damn fragile, but then every part of Windoze
is pretty damn fragile.  If it works as you say then it's good enough
for me, because I'm not ever going to buy into the premise that Postgres
on Windows is a production-grade setup.

            regards, tom lane