> Hmm... what if we took this a step further and actually stored the > checksums in a separate relation fork? That would make it pretty > simple to support enabling/disabling checksums for particular > relations. It would also allow us to have a wider checksum, like 32 > or 64 bits rather than 16. I'm not scoffing at a 16-bit checksum, > because even that's enough to catch a very high percentage of errors, > but it wouldn't be terrible to be able to support a wider one, either.
I don't remember exactly why this idea was sidelined before, but I don't think there were any showstoppers. It does have some desirable properties; most notably the ability to add checksums without a huge effort, so perhaps the idea can be revived. But there are some practical issues, as Tom points out. Another one is that it's harder for external utilities (like pg_basebackup) to verify checksums. And I just had another thought: these pages of checksums would be data pages, with an LSN. But as you clean ordinary data pages, you need to constantly bump the LSN of the very same checksum page (because it represents 1000 ordinary data pages); making it harder to actually clean the checksum page and finish a checkpoint. Is this a practical concern or am I borrowing trouble? Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers