* Jim C. Nasby: >> Anyway, how would be the chances for PostgreSQL to detect such a >> corruption on a heap or index data file? It's typically hard to >> detect this at the application level, so I don't expect wonders. I'm >> just curious if using PostgreSQL would have helped to catch this >> sooner. > > I know that WAL pages are (or at least were) CRC'd, because there was > extensive discussion around 32 bit vs 64 bit CRCs. CRCs wouldn't help because the out-of-date copy has got a correct CRC. That's why it's so hard to detect this problem at the application level. Putting redundancy into rows doesn't help, for instance. > There is no such check for data pages, although PostgreSQL has other > ways to detect errors. But in a nutshell, if you care about your > data, buy hardware you can trust. All hardware can fail. 8-/ AFAIK, compare-on-read is the recommend measure to compensate for this kind of failure. (The traditional recommendation also includes three disks, so that you've got a tie-breaker.) It seems to me that PostgreSQL's MVCC-related "don't directly overwrite data rows" policy might help to expose this sooner than with direct B-tree updates. In this particular case, we would have avoided the failure if we properly monitored the disk subsystem (the failure was gradual). Fortunately, it was just a test system, but it got me woried a bit.
