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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-bugs by date

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