On Sun, Dec 12, 2021 at 4:32 PM Thomas Munro <thomas.munro@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