Tom Lane wrote:
>Andrew Dunstan <andrew@dunslane.net> 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