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

Re: [Win32] Problem with rename()

From: "Magnus Hagander" <mha(at)sollentuna(dot)net>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Peter Brant" <Peter(dot)Brant(at)wicourts(dot)gov>,"Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>,"<Qingqing Zhou" <zhouqq(at)cs(dot)toronto(dot)edu>, <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: [Win32] Problem with rename()
Date: 2006-04-18 15:31:06
Message-ID: 6BCB9D8A16AC4241919521715F4D8BCEA352BA@algol.sollentuna.se (view raw or flat)
Thread:
Lists: pgsql-bugs
> > Looking at our code, we have the comment:
> > 	/* These flags allow concurrent rename/unlink */
> > 					(FILE_SHARE_READ |
> > FILE_SHARE_WRITE | FILE_SHARE_DELETE),
> 
> > But I'm not sure that those flags actually guarantee that. 
> They do allow
> > concurrent unlink, but not necessarily rename. I read 
> elsewhere that it
> > should work, but can't find backing docs on MSDN. Seems it 
> works in most
> > cases, but perhaps there are some where it doesn't?
> 
> I think there are two different cases involved in rename:
> 
> 1. Someone has a handle for the file-to-be-renamed;
> 2. Someone has a handle for the file that is to be deleted 
> (ie currently
>    has the name being renamed to).
> 
> If #2 doesn't work then we've got serious problems.  I think 
> though that
> #1 can only occur in the context of WAL segment recycling, so we can
> probably work around it if that doesn't work.

The problem reported here was 1. Nobody had handles to the new filename.
I don't think I've seen any reports of issue 2, but most were never
researched to this depth (because most were just a case of
uninstalling-the-antivirus-to-make-it-work).

//Magnus

pgsql-bugs by date

Next:From: Peter BrantDate: 2006-04-18 15:42:43
Subject: Re: [Win32] Problem with rename()
Previous:From: Tom LaneDate: 2006-04-18 15:28:20
Subject: Re: pre-existing shared memory block

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