Re: Defaulting wal_sync_method to fdatasync on Linux for 9.1?

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.

Thanks!

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
thereis 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
bothwork 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
notin 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@2ndQuadrant.com   Baltimore, MD
> PostgreSQL Training, Services and Support        www.2ndQuadrant.us
> "PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books
>