Re: BUG #16526: pg_test_fsync in v12 doesn't run in Windows

On Sat, Jul 04, 2020 at 10:03:56AM +0900, Michael Paquier wrote:
> I think that the error actually comes from 40cfe86, where we enforce
> O_TEXT in our port of open() for Windows so as the switch from WIN32's
> open() to our concurrent-safe version remains compatible. O_TEXT and
> FILE_FLAG_NO_BUFFERING are visibly incompatible together, and
> enforcing the call of open() in pg_test_fsync to use O_BINARY
> (actually PG_BINARY) when testing open_datasync() allows things to go
> through. So we are one call short of _setmode(), but it is more
> simple to pass down the flag when opening the fd. It may actually be
> safer in the long run to add the binary flag to all the calls of
> open() in pg_test_fsync. Thoughts?

So, I have been looking at that again. And, I am not completely sure
why the combination of FILE_FLAG_NO_BUFFERING and _setmode(O_TEXT)
would cause this failure, but I suspect that this is caused by the
fact that CRLF gets changed into single LF characters on input (input
buffer uses random data), causing the size of what's expected to be
written to not match with what is actually written. An additional
factor is visibly our wrapper safe-concurrent wrapper pgwin32_open().

It seems to me that it would be a better idea to just use the binary
mode for all the open() calls in pg_test_fsync in the long run, which
is what the attached patch does as there is no control on the data
written. This way, we avoid any translation that may happen during
the write. Any thoughts?
--
Michael