"Magnus Hagander" <[EMAIL PROTECTED]> 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
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.
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
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
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?