On Fri, Oct 1, 2010 at 3:50 AM, Peter Eisentraut <pete...@gmx.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers