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

Re: [Win32] Problem with rename()

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Magnus Hagander" <mha(at)sollentuna(dot)net>
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:18:08
Message-ID: 13419.1145373488@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugs
"Magnus Hagander" <mha(at)sollentuna(dot)net> writes:
> 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.

			regards, tom lane

In response to

pgsql-bugs by date

Next:From: Tom LaneDate: 2006-04-18 15:28:20
Subject: Re: pre-existing shared memory block
Previous:From: Ed L.Date: 2006-04-18 14:57:37
Subject: pre-existing shared memory block

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