Re: O_DSYNC broken on MacOS X? - Mailing list pgsql-hackers

From Greg Smith
Subject Re: O_DSYNC broken on MacOS X?
Date
Msg-id 4CA5333B.6010707@2ndquadrant.com
Whole thread Raw
In response to Re: O_DSYNC broken on MacOS X?  ("A.M." <agentm@themactionfaction.com>)
Responses Re: O_DSYNC broken on MacOS X?
List pgsql-hackers
A.M. wrote:
> That is not correct. fsync and friends on Darwin synchronizes I/O and flushes dirty kernel caches to the disk which
meetsthe specification and is distinctly different from doing nothing...
 
> "On MacOS X, fsync() always has and always will flush all file data
> from host memory to the drive on which the file resides."
> http://lists.apple.com/archives/Darwin-dev/2005/Feb/msg00072.html
>   

You didn't quote the next part of that, which says "fsync() is not 
sufficient to guarantee that your data is on stable
storage and on MacOS X we provide a fcntl(), called F_FULLFSYNC, to ask 
the drive to flush all buffered data to stable storage."  That's exactly 
what turning on fsync_writethrough does in PostgreSQL.  See 
http://archives.postgresql.org/pgsql-hackers/2005-04/msg00390.php as the 
first post on this topic that ultimately led to that behavior being 
implemented.
From the perspective of the database, whether or not the behavior is 
standards compliant isn't the issue.  Whether pages make it to physical 
disk or not when fsync is called, or when O_DSYNC writes are done on 
platforms that support them, is the important part.  If you the OS 
doesn't do that, it is doing nothing useful from the perspective of the 
database's expectations.  And that's not true on Darwin unless you 
specify F_FULLFSYNC, which doesn't happen by default in PostgreSQL.  It 
only does that when you switch wal_sync_method=fsync_writethrough

-- 
Greg Smith, 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD
PostgreSQL Training, Services and Support  www.2ndQuadrant.us
Author, "PostgreSQL 9.0 High Performance"    Pre-ordering at:
https://www.packtpub.com/postgresql-9-0-high-performance/book



pgsql-hackers by date:

Previous
From: KaiGai Kohei
Date:
Subject: Re: security hook on table creation
Next
From: Itagaki Takahiro
Date:
Subject: Re: I: About "Our CLUSTER implementation is pessimal" patch