Re: Final(?) proposal for wal_sync_method changes - Mailing list pgsql-hackers

From Greg Smith
Subject Re: Final(?) proposal for wal_sync_method changes
Date
Msg-id 4CFF1F7D.8060306@2ndquadrant.com
Whole thread Raw
In response to Re: Final(?) proposal for wal_sync_method changes  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> So actually, there is no difference between selecting fsync and
> fsync_writethrough on Windows, this comment and the SGML documentation
> to the contrary.  Both settings result in invoking _commit() and
> presumably are safe.  One wonders why we bothered to invent a separate
> fsync_writethrough setting on Windows.
>   

Quite; I documented some the details about mapping to _commit() long ago 
at http://www.westnet.com/~gsmith/content/postgresql/TuningPGWAL.htm but 
forgot to suggest fixing the mistakes in the docs afterwards (Windows is 
not exactly my favorite platform). 
http://archives.postgresql.org/pgsql-hackers/2005-08/msg00227.php 
explains some of the history I think you're looking for here.

> Would someone verify via pgbench or similar test (*not* test_fsync) that
> on Windows, wal_sync_method = fsync or fsync_writethrough perform the
> same (ie tps ~= disk rotation rate) while open_datasync is too fast to
> be real?  I'm losing confidence that I've found all the spaghetti ends
> here, and I don't have a Windows setup to try it myself.
>   

I can look into this tomorrow.  The laptop I posted Ubuntu/RHEL6 
test_fsync numbers from before also boots into Vista, so I can compare 
all those platforms on the same hardware.  I just need to be aware of 
the slightly different sequential speeds on each partition of the drive.

As far as your major battle plan goes, I think what we should do is find 
the simplest possible patch that just fixes the newer Linux kernel 
problem, preferrably without changing any other platform, then commit 
that to HEAD and appropriate backports.  Then the larger O_DIRECT 
remapping can proceed forward after that, along with cleanup to the 
writethrough choices and unifying test_fsync against the server.  I 
wrote a patch that shuffled around a lot of this code last night, but 
the first thing I coded was junk because of some mistaken assumptions.  
Have been coming to same realizations about how messy this really is you 
have.

-- 
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



pgsql-hackers by date:

Previous
From: aaliya zarrin
Date:
Subject: Re: To Signal The postmaster
Next
From: Magnus Hagander
Date:
Subject: Re: Final(?) proposal for wal_sync_method changes