Skip site navigation (1) Skip section navigation (2)

Re: rmtree() failure on Windows

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: rmtree() failure on Windows
Date: 2004-10-25 17:09:42
Message-ID: 21342.1098724182@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
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?

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Greg StarkDate: 2004-10-25 17:14:39
Subject: Re: [PATCHES] ARC Memory Usage analysis
Previous:From: Tom LaneDate: 2004-10-25 16:53:20
Subject: Re: Using ALTER TABLESPACE in pg_dump

pgsql-patches by date

Next:From: Greg StarkDate: 2004-10-25 17:14:39
Subject: Re: [PATCHES] ARC Memory Usage analysis
Previous:From: Reini UrbanDate: 2004-10-25 16:26:50
Subject: Re: rmtree() failure on Windows

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group