On Mon, Nov 12, 2012 at 4:44 AM, Craig Ringer <cr...@2ndquadrant.com> wrote: > That'll make it hard for VACUUM, hint-bit setting, etc to > opportunistically checksum pages whenever they're doing a page write anyway. > > Is it absurd to suggest using another bitmap, like the FSM or visibility > map, to store information on page checksumming while checksumming is > enabled but incomplete? As a much smaller file the bitmap could its self > be very quickly generated in one pass when checksumming is enabled, with > its starting state showing no pages having checksums.
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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
