Re: Final(?) proposal for wal_sync_method changes

From: Greg Smith <greg(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Final(?) proposal for wal_sync_method changes
Date: 2010-12-08 06:02:37
Message-ID: 4CFF1F7D.8060306@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)2ndQuadrant(dot)com Baltimore, MD
PostgreSQL Training, Services and Support www.2ndQuadrant.us
"PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2010-12-08 06:48:56 Re: Final(?) proposal for wal_sync_method changes
Previous Message aaliya zarrin 2010-12-08 05:12:25 Re: To Signal The postmaster