On mån, 2010-10-04 at 23:41 -0400, Robert Haas wrote:
> > 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.
That is explained in section 29.1 "Reliability".
> 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.
Right. It was true before fsync_writethrough was invented.
