Re: O_DSYNC broken on MacOS X?

From: Greg Smith <greg(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Dave Page <dpage(at)pgadmin(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: O_DSYNC broken on MacOS X?
Date: 2010-10-01 00:53:06
Message-ID: 4CA530F2.7070309@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)2ndQuadrant(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message KaiGai Kohei 2010-10-01 01:01:12 Re: security hook on table creation
Previous Message Josh Berkus 2010-10-01 00:21:36 Re: recovery.conf location