Re: wal_sync_method=fsync_writethrough

Поиск
Список
Период
Сортировка
От Magnus Hagander
Тема Re: wal_sync_method=fsync_writethrough
Дата
Msg-id CABUevExF9vVRXY3U9c0pANjXdXBC_V6Ju-m=v6vC-cPkJRU3aw@mail.gmail.com
обсуждение исходный текст
Ответ на wal_sync_method=fsync_writethrough  (Thomas Munro <thomas.munro@gmail.com>)
Ответы Re: wal_sync_method=fsync_writethrough
Список 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 по дате отправления:

Предыдущее
От: Justin Pryzby
Дата:
Сообщение: windows cfbot failing: my_perl
Следующее
От: Andrey Lepikhov
Дата:
Сообщение: Re: Removing unneeded self joins