Re: Allowing WAL fsync to be done via O_SYNC

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Allowing WAL fsync to be done via O_SYNC
Дата
Msg-id 14465.984680118@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Allowing WAL fsync to be done via O_SYNC  (Peter Eisentraut <peter_e@gmx.net>)
Ответы Re: Allowing WAL fsync to be done via O_SYNC  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: Allowing WAL fsync to be done via O_SYNC  (Peter Eisentraut <peter_e@gmx.net>)
Список pgsql-hackers
Peter Eisentraut <peter_e@gmx.net> writes:
> As a general rule, if something can be a run time option, as opposed to a
> compile time option, then it should be.  At the very least you keep the
> installation simple and allow for easier experimenting.

I've been mentally working through the code, and see only one reason why
it might be necessary to go with a compile-time choice: suppose we see
that none of O_DSYNC, O_SYNC, O_FSYNC, [others] are defined?  With the
compile-time choice it's easy: #define USE_FSYNC_FOR_WAL, and sail on.
If it's a GUC variable then we need a way to prevent the GUC option from
becoming unset (which would disable the fsync() calls, leaving nothing
to replace 'em).  Doable, perhaps, but seems kind of ugly ... any
thoughts about that?
        regards, tom lane


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

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