Re: O_DSYNC broken on MacOS X?

On Fri, Oct 1, 2010 at 3:50 AM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> On tor, 2010-09-30 at 15:07 -0700, Greg Stark wrote:
>> > It's too bad there is no cross-platform way to ask what level of
>> hardware-syncing is available.
>>
>> Why would the user want to ask this? As far as the user is concerned
>> either there are only two "levels": synced or not synced. If it's not
>> guaranteed to persist after a power failure it's not synced. It
>> doesn't matter whether it's in kernel buffers, drive buffers, or
>> anywhere else -- they're all the same from the user's point of view --
>> they're non-persistent.
>
> Well, it's not really useful, but that's how it works "everywhere".  On
> Linux, fsync carries the stuff from the kernel's RAM to the disk
> controller's RAM, and then it depends on some hdparm magic or something
> what happens next.

That's a bit vaguer than I'd like. TFD says "The aim of WAL is to
ensure that the log is written before database records are altered,
but this can be subverted by disk drives that falsely report a
successful write to the kernel, when in fact they have only cached the
data and not yet stored it on the disk. A power failure in such a
situation might lead to irrecoverable data corruption. Administrators
should try to ensure that disks holding PostgreSQL's WAL log files do
not make such false reports." This leaves open the question of how
they should attempt to do this; we should say what we know about that.

I also notice the following sentence in our documentation, which now
appears to me to be flat-out wrong: "The wal_sync_method parameter
determines how PostgreSQL will ask the kernel to force WAL updates
out to disk. All the options should be the same in terms of
reliability, but it's quite platform-specific which one will be the
fastest." Obviously, we know now (if we didn't before) that this
isn't the case, per my OP.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company