From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
---|---|
To: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | wal_sync_method=fsync_writethrough |
Date: | 2022-08-26 04:55:05 |
Message-ID: | CA+hUKGJ2CG2SouPv2mca2WCTOJxYumvBARRcKPraFMB6GSEMcA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
We allow $SUBJECT on Windows. I'm not sure exactly how we finished up
with that, maybe a historical mistake, but I find it misleading today.
Modern Windows flushes drive write caches for fsync (= _commit()) and
fdatasync (= FLUSH_FLAGS_FILE_DATA_SYNC_ONLY). In fact it is possible
to tell Windows to write out file data without flushing the drive
cache (= FLUSH_FLAGS_NO_SYNC), but I don't believe anyone is
interested in new weaker levels. Any reason not to just get rid of
it?
On macOS, our fsync and fdatasync levels *don't* flush drive caches,
because those system calls don't on that OS, and they offer a weird
special fcntl, so there we offer $SUBJECT for a good reason. Now that
macOS 10.2 systems are thoroughly extinct, I think we might as well
drop the configure probe, though, while we're doing a lot of that sort
of thing.
The documentation also says a couple of things that aren't quite
correct about wal_sync_level. (I would also like to revise other
nearby outdated paragraphs about volatile write caches, sector sizes
etc, but that'll take some more research.)
Attachment | Content-Type | Size |
---|---|---|
0001-Remove-wal_sync_method-fsync_writethrough-on-Windows.patch | text/x-patch | 3.3 KB |
0002-Remove-configure-probe-for-F_FULLSYNC.patch | text/x-patch | 3.1 KB |
0003-Doc-Corrections-to-claims-about-wal_sync_method.patch | text/x-patch | 3.9 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Kyotaro Horiguchi | 2022-08-26 05:07:51 | Re: Fix japanese translation of log messages |
Previous Message | Nathan Bossart | 2022-08-26 04:51:15 | Re: use ARM intrinsics in pg_lfind32() where available |