Tom Lane wrote:
> I wouldn't be too surprised if that rat's nest in InstallXLogFileSegment
> isn't right :-(. But we have to treat "file can't be renamed" as a
> nonfatal condition on Windows.
I added some debugging code, and I'm getting an ERROR_SHARING_VIOLATION
error when another program keeps the file open, while
InstallXLogFileSegment is checking for ERROR_ACCESS_DENIED. It seems
that check is flat-out wrong, as is the one in pgrename(). A bit of
googling suggests that Windows 9x might've returned ERROR_ACCESS_DENIED
in that case, so that's probably where that originated. pgwin32_open()
correctly checks for ERROR_SHARING_VIOLATION, but also for
ERROR_LOCK_VIOLATION.
I also note that since pgrename() doesn't set errno, the error message
printed in InstallXLogFileSegment if it fails is bogus. pgrename()
should set errno, using _dosmaperr().
A completely different approach would be to treat any failure on all
platforms as non-fatal. We shouldn't really cut the checkpoint short if
recycling a WAL file fails, whatever the reason. That seems like a more
robust approach than trying to guess which error codes are OK to ignore.
When called from XLogFileInit(), it's not expected that the target file
doesn't exist after InstallXLogFileSegment(), but it would just fail to
open it and throw an error anyway.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
