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

In response to

Responses

Browse pgsql-hackers by date

  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

Browse pgsql-patches by date

  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