"Tom Lane" <[EMAIL PROTECTED]> writes: > It's still pointless; a checksum does nothing to prevent data > corruption. The error report might be slightly more obvious to a novice > but it doesn't bring your data back.
Well if it's a single bit error from bad memory or a torn page from having full_page_writes turned off then the resulting page could be entirely valid. The user might not find out about the corrupt data before it's had time to migrate elsewhere. Also, the sooner the corrupt data is reported the sooner the user can restore from backups and avoid further data loss. The last discussion of this feature concentrated on beingg able to detect torn page corruption with full_page_writes turned off during recovery. > Something we could possibly do now is to modify these error messages: > if the transaction number we're trying to check is obviously bogus > (beyond the current XID counter or older than the current freeze > horizon) we could report it as a corrupted XID rather than exposing > the "no such clog segment" condition. That would be clever. I take it you mean the invalid values would be those values older than the actual relfrozenxid. Certainly they should throw some sort of error instead of trying to find the transaction in the clog. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
