On Tue, Oct 5, 2010 at 8:11 AM, Peter Eisentraut <pete...@gmx.net> wrote: > 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.
Proposed doc patch attached. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company
document-wal-caveats.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
