Re: BUG #16526: pg_test_fsync in v12 doesn't run in Windows
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Bruce Momjian <bruce@momjian.us>
Cc: jeff.janes@gmail.com, pgsql-bugs@lists.postgresql.org
Date: 2020-07-15T06:53:56Z
Lists: pgsql-bugs
On Tue, Jul 14, 2020 at 10:27:00AM -0400, Bruce Momjian wrote: > OK. I am kind of surprised we haven't received bug reports earlier, but > I guess few Windows users run pg_test_fsync, and fewer report problems. On 11 and older versions, we use O_TEXT with pg_test_fsync. This does not cause directly a failure, but those versions have as other problem to not be able to handle properly O_DSYNC, leading to tests of open_fdatasync to show extremely high and incorrect outputs: https://www.postgresql.org/message-id/1527864509.2475.49.camel@cybertec.at And it is the concurrent use of O_DSYNC with O_TEXT that's visibly causing a problem for 12~. O_DSYNC handling got addressed in v12 with 0ba06e0, and while changing back branches for ~11 to allow frontends to use our concurrent-safe version of fopen()/open() would be tempting, I don't think that fixing one test of pg_test_fsync is a reason enough to potentially risk breakages for other client tools inside, or even outside, the core tree. If there are no objections, I would like to just change the tool to use the binary mode down to 9.5. I can see that the text mode is getting used for all branches, and that's wrong as the aim is to test binary writes, basically as you said as well upthread. -- Michael
Commits
-
Switch pg_test_fsync to use binary mode on Windows
- ab7ce97ece57 9.5.23 landed
- a452b239e3b0 9.6.19 landed
- 800ec48f5ef2 10.14 landed
- de559c2b0642 11.9 landed
- cd113a0b4741 12.4 landed
- beebbb39d932 13.0 landed
- 932f9fb504a5 14.0 landed
-
Allow concurrent-safe open() and fopen() in frontend code for Windows
- 0ba06e0bfb8c 12.0 cited