| 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 |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Greg Stark | 2004-10-25 17:14:39 | Re: [PATCHES] ARC Memory Usage analysis |
| Previous Message | Tom Lane | 2004-10-25 16:53:20 | Re: Using ALTER TABLESPACE in pg_dump |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Greg Stark | 2004-10-25 17:14:39 | Re: [PATCHES] ARC Memory Usage analysis |
| Previous Message | Reini Urban | 2004-10-25 16:26:50 | Re: rmtree() failure on Windows |