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-26 17:16:31 |
Message-ID: | 10695.1098810991@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> 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.
If you rescan the directory after deleting the files, does it show
as empty?
> Bottom line, this is a real mess. Surely postgres is not the only
> application in the world that wants to be able to delete a directory
> tree reliably on Windows. What do other apps do?
I'm wondering if this is a side effect of the way win32_open does
things. It's hard to believe that rmdir is that bogus in general,
but perhaps win32_open is causing us to exercise a corner case?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-10-26 17:27:24 | Re: to_char/to_number loses sign |
Previous Message | Kurt Roeckx | 2004-10-26 16:32:51 | Re: Postgres performs a Seq Scan instead of an Index Scan! |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-10-26 17:27:24 | Re: to_char/to_number loses sign |
Previous Message | Tom Lane | 2004-10-26 16:06:54 | Re: pg_autovacuum vacuum cost variables patch |