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

Re: rmtree() failure on Windows

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Reini Urban <rurban(at)x-ray(dot)at>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: rmtree() failure on Windows
Date: 2004-10-27 14:02:17
Message-ID: 417FAA69.2080707@dunslane.net (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
problem area found. see below.

Reini Urban wrote:

> Andrew Dunstan schrieb:
>
>> Here is some more info. Below is a trace from dropdb. There is a loop 
>> around the rmdir() calls which I have set to time out at 600 seconds. 
>> The call eventually succeeds after around 300 seconds (I've seen this 
>> several times). It looks like we are the victim of some caching - the 
>> directory still thinks it has some of the files it has told us we 
>> have deleted successfully.
>
>
> 300 secs (!) fs timeout is really broken.
> Looks more like a locking or network timeout issue.
> What error codes does unlink(3) return?


success.

>
> Why don't you use DeletFileA() instead of unlink()?
>
> Or even better, why don't you use this delete on close snippet instead:


[snip]

Before I tried anything like that I tried one more thing. I disabled the 
background writer and the problem stopped. So now we know the "culprit".

>
>
> It should only happen a ERROR_SHARING_VIOLATION on NT systems with 
> such a long timeout. This is then a concurrency problem. win95 will 
> not return ERROR_SHARING_VIOLATION, only ERROR_ACCESS_DENIED
>
>
We don't support W95/W98/WME at all. The tests were done on XP-Pro.

cheers

andrew

In response to

Responses

pgsql-hackers by date

Next:From: Greg StarkDate: 2004-10-27 14:13:56
Subject: Re: plans for bitmap indexes?
Previous:From: Karel ZakDate: 2004-10-27 11:59:38
Subject: sign parsing (was: Re: [HACKERS] to_char/to_number loses sign)

pgsql-patches by date

Next:From: Reini UrbanDate: 2004-10-27 14:28:03
Subject: Re: rmtree() failure on Windows
Previous:From: Karel ZakDate: 2004-10-27 12:59:55
Subject: Re: 8.0-NLS: czech

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