On Sat, Aug 27, 2022 at 12:17 AM Magnus Hagander <mag...@hagander.net> wrote: > So, I don't know how it works now, but the history at least was this: > it was not about the disk caches, it was about raid controller caches. > Basically, we determined that windows didn't fsync it all the way. But > it would with But if we changed wal_sync_method=fsync to actually > *do* that, then people who had paid big money for raid controllers > with flash or battery backed cache would lose a ton of performance. So > we needed one level that would sync out of the OS but not through the > RAID cache, and another one that would sync it out of the RAID cache > as well. Which would/could be different from the drive caches > themselves, and they often behaved differently. And I think it may > have even been dependent on the individual RAID drivers what the > default would be.
Thanks for the background. Yeah, that makes sense to motivate open_datasync for Windows. Not sure what you meant about fsync or meant to write after "would with". It seems like the 2005 discussions were primarily about open_datasync but also had the by-product of introducing the name fsync_writethrough. If I'm reading between the lines[1] correctly, perhaps the logic went like this: 1. We noticed that _commit() AKA FlushFileBuffers() issued SYNCHRONIZE CACHE (or equivalent) on Windows. 2. At that time in history, Linux (and other Unixes) probably did not issue SYNCHRONIZE CACHE when you called fsync()/fdatasync(). 3. We concluded therefore that Windows was strange and we needed to use a different level name for the setting to reflect this extra effect. Now it looks strange: we have both "fsync" and "fsync_writethrough" doing exactly the same thing while vaguely implying otherwise, and the contrast with other operating systems (if I divined that aspect correctly) mostly doesn't apply. How flush commands affect various caches in modern storage stacks is also not really OS-specific AFAIK. (Obviously macOS is a different story...) [1] https://www.postgresql.org/message-id/flat/26109.1111084860%40sss.pgh.pa.us#e7f8c2e14d76cad76b1857e89c8a6314