Re: Fwd: Apple Darwin disabled fsync? - Mailing list pgsql-hackers

From Jim C. Nasby
Subject Re: Fwd: Apple Darwin disabled fsync?
Date
Msg-id 20050222053741.GL86914@decibel.org
Whole thread Raw
In response to Re: Fwd: Apple Darwin disabled fsync?  (Greg Stark <gsstark@mit.edu>)
Responses New wal_sync_method for Darwin?  (Chris Campbell <chris@bignerdranch.com>)
List pgsql-hackers
On Sun, Feb 20, 2005 at 10:50:35PM -0500, Greg Stark wrote:
> 
> Peter Bierman <bierman@apple.com> writes:
> 
> > I think the intent of fsync() is closer to what you describe, but the
> > convention is that fsync() hands responsibility to the disk hardware.
> 
> The "convention" was also that the hardware didn't confirm the command until
> it had actually been executed...
> 
> None of this matters to the application. A specification for fsync(2) that
> says it forces the data to be shuffled around under the hood but fundamentally
> the doesn't change the semantics (that the data isn't guaranteed to be in
> non-volatile storage) means that fsync didn't really do anything.

The real issue is this isn't specific to OS X. I know FreeBSD enables
write-caching on IDE drives by default, and I suspect linux does as
well. It's probably worth adding a big, fat WARNING in the docs in
strategic places about this.
-- 
Jim C. Nasby, Database Consultant               decibel@decibel.org 
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: psql: recall previous command?
Next
From: Tom Lane
Date:
Subject: Re: left-deep plans?