RE: Allowing WAL fsync to be done via O_SYNC

Поиск
Список
Период
Сортировка
От Mikheev, Vadim
Тема RE: Allowing WAL fsync to be done via O_SYNC
Дата
Msg-id 8F4C99C66D04D4118F580090272A7A234D3321@sectorbase1.sectorbase.com
обсуждение исходный текст
Ответ на Allowing WAL fsync to be done via O_SYNC  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Allowing WAL fsync to be done via O_SYNC  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Allowing WAL fsync to be done via O_SYNC  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список pgsql-hackers
> Based on the tests we did last week, it seems clear than on many
> platforms it's a win to sync the WAL log by writing it with open()
> option O_SYNC (or O_DSYNC where available) rather than 
> issuing explicit fsync() (resp. fdatasync()) calls.

I don't remember big difference in using fsync or O_SYNC in tfsync
tests. Both depend on block size and keeping in mind that fsync
allows us syncing after writing *multiple* blocks I would either
use fsync as default or don't deal with O_SYNC at all.
But if O_DSYNC is defined and O_DSYNC != O_SYNC then we should
use O_DSYNC by default.
(BTW, we didn't compare fdatasync and O_SYNC yet).

Vadim


В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Ross J. Reedstrom"
Дата:
Сообщение: Re: rtrim giving weird result
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Allowing WAL fsync to be done via O_SYNC