Re: rmtree() failure on Windows - Mailing list pgsql-hackers

From Tom Lane
Subject Re: rmtree() failure on Windows
Date
Msg-id 20818.1098720933@sss.pgh.pa.us
Whole thread Raw
In response to Re: rmtree() failure on Windows  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
Andrew Dunstan <andrew@dunslane.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


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: rmtree() failure on Windows
Next
From: Fabien COELHO
Date:
Subject: Re: Using ALTER TABLESPACE in pg_dump