Re: Idea for fixing the Windows fsync problem

"Magnus Hagander" <magnus@hagander.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
directorybecause 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