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+
|
| Список | 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 по дате отправления: