On 05.09.2012 14:28, Tom Lane wrote:
> Heikki Linnakangas<hlinnaka@iki.fi> writes:
>> That doesn't work on Windows. As long as a walsender is keeping the old
>> file open, the unlink() on it fails. You get an error like this in the
>> startup process:
>> FATAL: could not rename file "pg_xlog/RECOVERYXLOG" to
>> "pg_xlog/00000001000000000000000D": Permission denied
>
> I thought we had some workaround for that problem. Otherwise, you'd be
> seeing this type of failure every time a checkpoint tries to drop or
> rename files.
Hmm, now that I look at the error message more carefully, what happens
is that the unlink() succeeds, but when the startup process tries to
rename the new file in place, the rename() fails. The comments in
RemoveOldXLogFiles() explains that, and also shows how to work around it:
> /*
> * On Windows, if another process (e.g another backend)
> * holds the file open in FILE_SHARE_DELETE mode, unlink
> * will succeed, but the file will still show up in
> * directory listing until the last handle is closed. To
> * avoid confusing the lingering deleted file for a live
> * WAL file that needs to be archived, rename it before
> * deleting it.
> *
> * If another process holds the file open without
> * FILE_SHARE_DELETE flag, rename will fail. We'll try
> * again at the next checkpoint.
> */
I think we need the same trick here, and rename the old file first, then
unlink() it, and then rename the new file in place. I'll try that out..
- Heikki