Re: [PATCH] Revert default wal_sync_method to fdatasync on Linux 2.6.33+

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [PATCH] Revert default wal_sync_method to fdatasync on Linux 2.6.33+
Дата
Msg-id 3002.1288994830@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [PATCH] Revert default wal_sync_method to fdatasync on Linux 2.6.33+  (Andres Freund <andres@anarazel.de>)
Ответы Re: [PATCH] Revert default wal_sync_method to fdatasync on Linux 2.6.33+  (Josh Berkus <josh@agliodbs.com>)
Список pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> On Friday 05 November 2010 19:13:47 Tom Lane wrote:
>> If open_dsync is so bad for performance on Linux, maybe it's bad
>> everywhere?  Should we be rethinking the default preference order?

> I fail to see how it could be beneficial on *any* non-buggy platform.
> Especially with small wal_buffers and larger commits (but also otherwise) it 
> increases the amount of synchronous writes the os has to do tremendously.

> * It removes about all benefits of XLogBackgroundFlush() 
> * It removes any chances of reordering after writing.
> * It makes AdvanceXLInsertBuffer synchronous if it has to write outy 

> Whats the theory about placing it so high in the preferences list?

I think the original idea was that if you had a dedicated WAL drive then
sync-on-write would be reasonable.  But that was a very long time ago
and I'm not sure that the system's behavior is anything like what it was
then; for that matter I'm not sure we had proof that it was an optimal
choice even back then.  That's why I want to revisit the choice of
default and not just go for "minimum" change.
        regards, tom lane


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Query Plan Columns
Следующее
От: Andres Freund
Дата:
Сообщение: Re: [PATCH] Revert default wal_sync_method to fdatasync on Linux 2.6.33+