From: | "Jim C(dot) Nasby" <decibel(at)decibel(dot)org> |
---|---|
To: | Greg Stark <gsstark(at)mit(dot)edu> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Fwd: Apple Darwin disabled fsync? |
Date: | 2005-02-22 05:37:41 |
Message-ID: | 20050222053741.GL86914@decibel.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Feb 20, 2005 at 10:50:35PM -0500, Greg Stark wrote:
>
> Peter Bierman <bierman(at)apple(dot)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(at)decibel(dot)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?"
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-02-22 06:04:20 | Re: left-deep plans? |
Previous Message | Alvaro Herrera | 2005-02-22 04:48:22 | Re: psql: recall previous command? |