Skip site navigation (1) Skip section navigation (2)

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: Reini Urban <rurban(at)x-ray(dot)at>,PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: rmtree() failure on Windows
Date: 2004-10-27 15:58:09
Message-ID: 20803.1098892689@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> Tom Lane wrote:
>> One relatively low-impact workaround would be to force a checkpoint
>> (on Windows only) during DROP DATABASE, just before we actually fire
>> the rmtree() operation.  The bgwriter is already coded to close all its
>> open files after a checkpoint ...

> Works for me. If someone gives me a patch I'll be happy to test it.

Try putting "RequestCheckpoint(true)" in dbcommands.c just before
remove_dbtablespaces (about line 630).

It looks like the bgwriter is not quite up-to-speed for this, either;
you should rearrange things near line 350 of bgwriter.c so that 
smgrcloseall is performed before marking the checkpoint done in shmem.
Else RequestCheckpoint could come back before the files are all closed.

> I did wonder if there should be a call that instead of forcing a flush 
> could tell bgwriter just to forget about the file(s) because we're 
> discarding them. But that was just idle speculation - I haven't looked 
> at bgwriter at all.

Not necessary, as long as you put the checkpoint after the DropBuffers
call in dbcommands.c.  The bgwriter won't find anything to write.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2004-10-27 16:00:35
Subject: Re: rmtree() failure on Windows
Previous:From: Andrew DunstanDate: 2004-10-27 15:43:39
Subject: Re: rmtree() failure on Windows

pgsql-patches by date

Next:From: Tom LaneDate: 2004-10-27 16:00:35
Subject: Re: rmtree() failure on Windows
Previous:From: Devrim GUNDUZDate: 2004-10-27 15:57:00
Subject: Updated Turkish translations

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group