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 16:15:33 |
Message-ID: | 20818.1098720933@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:
> Tom Lane wrote:
>> I kinda suspect that what you are looking at is a problem with the
>> delayed-unlinking feature that we built to cope with Windows' inability
>> to unlink open files, ie, it's being a little too slow to do the
>> unlinks. Would you refresh my memory about exactly where and when the
>> unlink happens if the initial try fails?
>>
> Same file, although Bruce says that looping code is now redundant, as we
> open files in a way that allows unlinking even if they are open.
Does the problem go away if you insert a "sleep 1" at the bottom of the
pg_regress script? I have been thinking of proposing that anyway,
because on some platforms I consistently get "database removal failed:
database "regression" is being accessed by other users" failures from
the contrib regression tests because the previous backend doesn't get
enough time to quit before the next test tries to drop and recreate the
regression database. I think what you are looking at may be some
variant of the same issue, ie, old backend still running.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Fabien COELHO | 2004-10-25 16:18:17 | Re: Using ALTER TABLESPACE in pg_dump |
Previous Message | Tom Lane | 2004-10-25 16:03:12 | Re: [PATCHES] ARC Memory Usage analysis |
From | Date | Subject | |
---|---|---|---|
Next Message | Reini Urban | 2004-10-25 16:26:50 | Re: rmtree() failure on Windows |
Previous Message | Tom Lane | 2004-10-25 16:03:12 | Re: [PATCHES] ARC Memory Usage analysis |