Greg Stark <[EMAIL PROTECTED]> writes: > Tom Lane <[EMAIL PROTECTED]> writes: >> It's not really a matter of backstopping the hardware's error detection; >> if we were trying to do that, we'd keep a CRC for every data page, which >> we don't. The real reason for the WAL CRCs is as a reliable method of >> identifying the end of WAL: when the "next record" doesn't checksum you >> know it's bogus.
> Is the random WAL data really the concern? It seems like a more reliable way > of dealing with that would be to just accompany every WAL entry with a > sequential id and stop when the next id isn't the correct one. We do that, too (the xl_prev links and page header addresses serve that purpose). But it's not sufficient given that WAL records can span pages and therefore may be incompletely written. > The only truly reliable way to handle this would require two fsyncs per > transaction commit which would be really unfortunate. How are two fsyncs going to be better than one? regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings