Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Another data point - when rmdir() fails it fails quickly, but when unlink (i.e. our pg_unlink()) fails it takes a very long time (minutes) to fail. And the file is actually not there. So it looks like we loop over and over and keep getting EACCESS, and then get ENOENT, but the last one that failed with EACCESS actually succeeded. *sigh*
... or someone else deleted it in between our last EACCESS failure and the ENOENT try. What someone else would that be? More than likely, the same guy who was holding it open to cause the EACCESS failures.
Perhaps there are paths in the code that don't go through win32_open?
Well, on looking at the MS API at http://msdn.microsoft.com/library/en-us/vclib/html/vcrefRunTimeLibraryReference.asp I see that opendir() and friends aren't there, which means we might be at the mercy of what mingw does for us.
If I increase the sleep time before dropdb enormously (35 secs) the unlink errors seem to go away, and instead they become rmdir errors like the rest.
I am wondering if we need to look at using direct calls to the Windows API (findfirst() and friends).
cheers
andrew
---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
