Re: Idea for fixing the Windows fsync problem

"Magnus Hagander" <magnus(at)hagander(dot)net> writes:
>> BTW: what happens on Windows if we're trying to do the equivalent
>> of "rm -rf database-dir" and someone is holding open one of the
>> files in the directory? Or has the directory itself open for readdir()?

> For the first definity and I think for the second, when doing it from the commandline, you get a 'cannot delete the directory because it is not empty'.
> I'm not sure if our implementation for dealing with open files also work with directories.

I just noticed this in dropdb():

/*
* On Windows, force a checkpoint so that the bgwriter doesn't hold any
* open files, which would cause rmdir() to fail.
*/
#ifdef WIN32
RequestCheckpoint(true, false);
#endif

This is done after flushing shared buffers (and, in a little bit, after
telling the bgwriter to forget pending fsyncs); so there'd be no reason
for the bgwriter to re-open any files in the victim database. And there
are other interlocks guaranteeing no active backends in the victim
database.

It's still not 100% bulletproof, because it's possible that some other
backend is holding an open file in the database as a consequence of
having had to dump some shared buffer for itself, but that should be
pretty darn rare if the bgwriter is getting its job done.

regards, tom lane