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-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

In response to

Responses

Browse pgsql-hackers by date

  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!

Browse pgsql-patches by date

  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