Re: wal_sync_method=fsync_writethrough - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: wal_sync_method=fsync_writethrough
Date
Msg-id CABUevExF9vVRXY3U9c0pANjXdXBC_V6Ju-m=v6vC-cPkJRU3aw@mail.gmail.com
Whole thread Raw
In response to wal_sync_method=fsync_writethrough  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: wal_sync_method=fsync_writethrough
List pgsql-hackers
On Fri, Aug 26, 2022 at 6:55 AM Thomas Munro <thomas.munro@gmail.com> wrote:
>
> 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?

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.

-- 
 Magnus Hagander
 Me: https://www.hagander.net/
 Work: https://www.redpill-linpro.com/



pgsql-hackers by date:

Previous
From: Justin Pryzby
Date:
Subject: windows cfbot failing: my_perl
Next
From: Andrey Lepikhov
Date:
Subject: Re: Removing unneeded self joins