Re: [PATCH] Revert default wal_sync_method to fdatasync on Linux 2.6.33+ - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [PATCH] Revert default wal_sync_method to fdatasync on Linux 2.6.33+
Date
Msg-id 3002.1288994830@sss.pgh.pa.us
Whole thread Raw
In response to Re: [PATCH] Revert default wal_sync_method to fdatasync on Linux 2.6.33+  (Andres Freund <andres@anarazel.de>)
Responses Re: [PATCH] Revert default wal_sync_method to fdatasync on Linux 2.6.33+
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: Query Plan Columns
Next
From: Andres Freund
Date:
Subject: Re: [PATCH] Revert default wal_sync_method to fdatasync on Linux 2.6.33+