On Sun, Dec 12, 2021 at 4:32 PM Thomas Munro <thomas.mu...@gmail.com> wrote: > One reason to consider developing this further is the problem > discussed in the aptly named thread "Loaded footgun open_datasync on > Windows"[1] (not the problem that was fixed in pg_test_fsync, but the > problem with cache control, or lack thereof). I saw 10x more TPS with > open_datasync than with this experimental fdatasync on my little test > VM, which was more than a little fishy, so I turned off the device > write caching in "Device Manager" and got about the same number from > open_datasync and fdatasync. Clearly you can lose committed > transactions on power loss[2] with the default OS settings and default > PostgreSQL settings, though perhaps only if you're on SATA storage due > to lack of FUA pass-through[3] (?). I didn't try an NVMe stack. > > That suggests that fdatasync would actually be a better default ... > except for the problems already mentioned with versions and not > working on non-NTFS (not sure how it fails on non-NTFS, though, maybe > it does a full flush, [4] doesn't say).
So my impression is that today we ship defaults that are unsafe on Windows. I don't really understand much of what you are saying here, but if there's a way we can stop doing that, +1 from me, especially if it allows us to retain reasonable performance. -- Robert Haas EDB: http://www.enterprisedb.com
