> > 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
pgsql-bugs by date
|Next:||From: Peter Brant||Date: 2006-04-18 15:42:43|
|Subject: Re: [Win32] Problem with rename()|
|Previous:||From: Tom Lane||Date: 2006-04-18 15:28:20|
|Subject: Re: pre-existing shared memory block |