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

Tom Lane wrote:
> Claudio Natoli <claudio.natoli@memetrics.com> writes:
> > Tom, can you hold off on "unlink handling" part of the
> > implementation, at least for a few days?
>
> Love to ;-)

Figured this wouldn't cause you too much grief :-)


> > I'm testing a patch right now to work around this very
> > issue (involves, under win32, replacing _open() with CreateFile, which
> > accepts parameters to allow deletion of the held file.
> > Initial testing looks good, but it'll need community review).
>
> However, I don't see exactly how that can win?

Why not?

In any case, attached is the code I've currently got. Comments/criticisms
most welcome.

FWIW, replacing the call to open() (strictly, _open() under win32) in
BasicOpenFile (fd.c) with this win32_open() allows the regression tests to
pass through the transactions, foreign_key, and alter_table tests without
locking up (which is what they currently do). All in all, the change looks
sound, however I make no guarantee that a corner case has not been missed.

[One thing I have noticed is that database directories don't get removed
when dropping the db, leaving a whole stack of empty directories when
running the regression tests in a loop. However, this could very well be
pre-existing.]

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:
>> 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.

Moreover, allowing overwrite when the code isn't otherwise expecting
it takes away a fairly significant error check, namely that we don't
accidentally assign the same relfilenode to two different relations.
At the moment I think that failure during open() is our *only* line
of defense against relfilenode collision.  Even if we were willing
to add the overhead of an otherwise-useless unique index on
pg_class.relfilenode, I'd not really want to give up the open() check.
Stomping on someone else's file is just too disastrous...

AFAIR the only case where we're really deleting files with the intention
of replacing them shortly is in the code paths that initially write a
temp file and then rename it into place.  Open-with-overwrite is no help
there anyway, because it would mean giving up the existing defenses
against readers seeing inconsistent intermediate states of the file.

So unless I'm totally misunderstanding where you mean to use this code,
I don't see the point.

            regards, tom lane