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 4CA530F2.7070309@2ndquadrant.com
Whole thread Raw
In response to Re: O_DSYNC broken on MacOS X?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> I'm not sure whether we should select fsync_writethrough as the default
> on OSX.  We don't make an equivalent attempt to prevent OS or storage
> malfeasance on other Unixoid platforms --- in fact, I'd say OSX is a bit
> ahead of the game in that you *can* force writethrough without resorting
> to arcane hacks with hdparm or some such.
>   

The same issue exists on Windows too, with the same workaround:  
normally unsafe by default, have to switch to fsync_writethrough in 
order to get commit safety and write caching for regular writes, still 
ahead of most Unixes because at least it's that easy.

The main downside to switching the default on either OS X or Windows is 
developers using those platforms for test deployments will suffer 
greatly from a performance drop for data they don't really care about.  
As those two in particular are much more likely to be client development 
platforms, too, that's a scary thing to consider.

As for the documentation, I wrote 
http://www.westnet.com/~gsmith/content/postgresql/TuningPGWAL.htm a 
while ago trying to address this better, but never got to merging some 
of those notes into the official docs.  At the time, such heavy linking 
to external URLs was particularly frowned upon in the official docs.  
While that's eased up a bit, what I think I could do now is convert that 
article into something that's on the Wiki instead, and we could point 
the "Reliability" section of the docs toward there as something that 
could stay live as platform-specific changes happen.  I'm thinking of 
the whole ext4 behavior change when I say that; stuff like that will 
only be addressable in a live document, since changes were happening in 
between major releases in that area.

More recently, I've written a few things covering this area in what 
approaches excruciating detail, for this little document you might have 
been spammed in somebody's signature about.  I'm going to ask the 
publisher to make that specific material the public sample chapter for 
the book, in hopes of making it easier for people to find a detailed 
discussion of this topic.  Regardless of whether that works out, I have 
to clean up documentation in this whole area up for the checkpoint 
changes I'm working on for 9.1 anyway.  That tinkers with the timing on 
fsync calls, and whether that works or not is very filesystem specific.  
I'm basically stuck with documenting exactly what happens for most 
possibilities in order to provide a comprehensive manual section 
covering that.  I have a deadline for when I have to get my work in 
progress organized to share with the world now:  
https://www.postgresqlconference.org/content/righting-your-writes , so 
after I get back from that conference in November I'll see what I can do 
about the docs too.

-- 
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: Josh Berkus
Date:
Subject: Re: recovery.conf location
Next
From: KaiGai Kohei
Date:
Subject: Re: security hook on table creation