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: