Re: Windows now has fdatasync()

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Windows now has fdatasync()
Date: 2022-02-04 13:10:21
Message-ID: CA+TgmoYEBe1cmqudRNZKjTcEsU4J6W=xBof2u2afeEDsZ6jT8Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Dec 12, 2021 at 4:32 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2022-02-04 13:46:39 Re: make MaxBackends available in _PG_init
Previous Message Amit Kapila 2022-02-04 12:20:46 Re: Bugs in pgoutput.c