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
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 |