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?
> Why don't you use DeletFileA() instead of unlink()?
> Or even better, why don't you use this delete on close snippet instead:
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.
In response to
pgsql-hackers by date
|Next:||From: Greg Stark||Date: 2004-10-27 14:13:56|
|Subject: Re: plans for bitmap indexes?|
|Previous:||From: Karel Zak||Date: 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 Urban||Date: 2004-10-27 14:28:03|
|Subject: Re: rmtree() failure on Windows|
|Previous:||From: Karel Zak||Date: 2004-10-27 12:59:55|
|Subject: Re: 8.0-NLS: czech|