Skip site navigation (1) Skip section navigation (2)

Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1?

From: Scott Carey <scott(at)richrelevance(dot)com>
To: Greg Smith <greg(at)2ndquadrant(dot)com>
Cc: Marti Raudsepp <marti(at)juffo(dot)org>, "pgsql-performance(at)postgresql(dot)org"<pgsql-performance(at)postgresql(dot)org>
Subject: Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1?
Date: 2010-11-17 23:20:15
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
On Nov 17, 2010, at 1:24 PM, Greg Smith wrote:

> Scott Carey wrote:
>> Did you recompile your test on the RHEL6 system? 
> On both systems I showed, I checked out a fresh copy of the PostgreSQL 
> 9.1 HEAD from the git repo, and compiled that on the server, to make 
> sure I was pulling in the appropriate kernel headers.  I wasn't aware of 
> exactly how the kernel sync stuff was refactored though, thanks for the 
> concise update on that.  


So this could be another bug in Linux.  Not entirely surprising.
Since fsync/fdatasync relative performance isn't similar to open_sync/open_datasync relative performance on this test there is probably a bug that either hurts fsync, or one that is preventing open_sync from dealing with metadata properly.   Luckily for the xlog, both of those can be avoided -- the real choice is fdatasync vs open_datasync.  And both work in newer kernels or break in certain older ones.

> I can do similar tests on a RHEL5 system, but 
> not on the same hardware.  Can only make my laptop boot so many 
> operating systems at a time usefully.

Yeah, I understand.  I might throw this at a RHEL5 system if I get a chance but I need one without a RAID card that is not in use.  Hopefully it doesn't turn out that fdatasync is write-cache safe but open_sync/open_datasync isn't on that platform.  It could impact the choice of a default value.

> -- 
> Greg Smith   2ndQuadrant US    greg(at)2ndQuadrant(dot)com   Baltimore, MD
> PostgreSQL Training, Services and Support
> "PostgreSQL 9.0 High Performance":

In response to

pgsql-performance by date

Next:From: Tom LaneDate: 2010-11-17 23:21:18
Subject: Re: Query Performance SQL Server vs. Postgresql
Previous:From: Ivan VorasDate: 2010-11-17 22:53:58
Subject: Re: Anyone seen this kind of lock pileup?

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group