"Scott Marlowe" <scott.marlowe@xxxxxxxxx> writes: > On Sat, Mar 1, 2008 at 4:27 AM, Franck Routier <franck.routier@xxxxxxxxx> wrote: >> Well, am I just wrong, or the file system might also heavily rely on >> cache, especially as I use XFS ? >> >> So anyway Postgresql has no way to know if the data is really on the >> disk, and in case of a brutal outage, the system may definitely lose >> data, wether there is another level of caching (Raid controller) or >> not... > nope. assuming your disk subsystem doesn't lie about write > completion, then postgresql can recover from complete and sudden loss > of power without any data loss. Franck does have a point here: we are expecting the filesystem to tend to its own knitting. If a power failure corrupts the filesystem so badly that we can't find the WAL files, or their contents are badly scrambled, then we're screwed. Most modern filesystems defend themselves against that using journaling, which is exactly the same idea as WAL but applied to filesystem metadata. We do expect that when we fsync a file, by the time the OS reports that that's done both the file contents and its metadata are safely on disk. This is part of the specification for fsync, so the OS is clearly broken if it doesn't get that right. Whether the OS *can* guarantee it if the disk drive lies about write completion is something you'd have to ask the filesystem hackers about. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match