Re: Permission denied on fsync / Win32 (was right

"Peter Brant" <Peter(dot)Brant(at)wicourts(dot)gov> writes:
> Here's the evidence from this morning. I have to admit I'm not really
> sure what to make of it though.
> ...
> - Same pattern as Server #1. bgwriter has a handle to the new
> relfilenode. Other backends have a handle to either old or new.

It seems pretty clear to me that the problem occurs when we try to
fsync the old relfilenode, which is in a pending-delete state but
hasn't been deleted yet because of the presence of open handles in
some backends. (Peter, did you check that the error messages in
the postmaster log all refer to old relfilenodes not new ones?)

We should be able to ignore this error, but I'm certainly unwilling
to just treat EACCES in general as an ignorable error. So the problem
is to distinguish this case from genuine permission failures. Perhaps
ERROR_SHARING_VIOLATION should be mapped to something other than EACCES?
It seems like that's a rather poor fit. Or we could leave the mapping
as-is and add an #ifdef'd test on GetLastError to mdsync() (ugly...)

One worry is whether there are any other possible causes of
ERROR_SHARING_VIOLATION during fsync, and if so are they all ignorable.

regards, tom lane