Re: Allowing WAL fsync to be done via O_SYNC

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: Allowing WAL fsync to be done via O_SYNC
Дата
Msg-id Pine.LNX.4.30.0103152226410.826-100000@peter.localdomain
обсуждение исходный текст
Ответ на 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  (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
Tom Lane writes:

> "Mikheev, Vadim" <vmikheev@SECTORBASE.COM> writes:
> > ... 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.
>
> Hm.  We could do that reasonably painlessly as a compile-time test in
> xlog.c, but I'm not clear on how it would play out as a GUC option.
> Peter, what do you think about configuration-dependent defaults for
> GUC variables?

We have plenty of those already, but we should avoid a variable whose
specification is:

"The default is 'on' if your system defines one of the macros O_SYNC,
O_DSYNC, O_FSYNC, and if O_SYNC and O_DSYNC are distinct, otherwise the
default is 'off'."

The net result of this would be that the average user would have
absolutely no clue what the default on his machine is.

Additionally consider that maybe O_SYNC and O_DSYNC have different values
but the kernel treats them the same anyway.  We really shouldn't try to
guess that far.

-- 
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/



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

Предыдущее
От: Roberto Mello
Дата:
Сообщение: Contribute to the PL/pgSQL CookBook !!
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: Allowing WAL fsync to be done via O_SYNC