Michael Paquier <michael@paquier.xyz> writes:
> On Wed, Nov 04, 2020 at 01:24:46PM +0100, Andreas Kretschmer wrote:
>> wild guess: Antivirus Software?
> Perhaps not. To bring more context in here, PostgreSQL opens any
> files on WIN32 with shared writes and reads allowed to have an
> equivalent of what we do on all *nix platforms. Note here that the
> problem comes from a WAL segment write, which is done after the file
> handle is opened in shared mode. As long as the fd is correctly
> opened, any attempt for an antivirus software to open a file with an
> exclusive write would be blocked, no?
The only hard data point we've got here is the "Invalid argument"
string, which should mean EINVAL, although I'm not entirely sure
where that string is determined in a Windows build. So it seems
like there are two possibilities:
* The actual underlying Windows error code is one of the ones
that win32error.c maps to EINVAL:
ERROR_INVALID_FUNCTION, EINVAL
ERROR_INVALID_ACCESS, EINVAL
ERROR_INVALID_DATA, EINVAL
ERROR_INVALID_PARAMETER, EINVAL
ERROR_INVALID_HANDLE, EINVAL
ERROR_NEGATIVE_SEEK, EINVAL
* The actual underlying Windows error code is something that
win32error.c doesn't know, which would cause _dosmaperr() to
return EINVAL.
The latter case would result in a LOG message "unrecognized win32 error
code", so it would be good to know if any of those are showing up in
the postmaster log.
Seems like maybe it wasn't a great idea for _dosmaperr's fallback
errno to be something that is also a real error code.
regards, tom lane
