Re: rmtree() failure on Windows

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: rmtree() failure on Windows
Date: 2004-10-25 21:01:39
Message-ID: 417D69B3.9060808@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Tom Lane wrote:

>Andrew Dunstan <andrew(at)dunslane(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2004-10-25 21:15:23 Re: rmtree() failure on Windows
Previous Message Josh Berkus 2004-10-25 20:54:53 Lamar stepping down

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2004-10-25 21:15:23 Re: rmtree() failure on Windows
Previous Message Greg Stark 2004-10-25 17:14:39 Re: [PATCHES] ARC Memory Usage analysis