Re: Enabling Checksums

On 3/3/13 9:22 AM, Craig Ringer wrote:
> Did you get a chance to see whether you can run it in
> checksum-validation-and-update-off backward compatible mode? This seems
> like an important thing to have working (and tested for) in case of
> bugs, performance issues or other unforseen circumstances.

There isn't any way to do this in the current code. The big
simplification Jeff introduced here, to narrow complexity toward a
commit candidate, was to make checksumming a cluster-level decision.
You get it for everything or not at all.

The problem I posted about earlier today, where a header checksum error
can block access to the entire relation, could be resolved with some
sort of "ignore read checksums" GUC. But that's impractical right now
for the write side of things. There have been a long list of metadata
proposals to handle situations where part of a cluster is checksummed,
but not all of it. Once that sort of feature is implemented, it becomes
a lot easier to talk about selectively disabling writes.

As for a design of a GUC that might be useful here, the option itself
strikes me as being like archive_mode in its general use. There is an
element of parameters like wal_sync_method or enable_cassert though,
where the options available vary depending on how you built the cluster.
Maybe name it checksum_level with options like this:

off: only valid option if you didn't enable checksums with initdb
enforcing: full checksum behavior as written right now.
unvalidated: broken checksums on reads are ignored.

The main tricky case I see in that is where you read in a page with a
busted checksum using "unvalidated". Ideally you wouldn't write such a
page back out again, because it's going to hide that it's corrupted in
some way already. How to enforce that though? Perhaps "unvalidated"
only be allowed in a read-only transaction?

--
Greg Smith 2ndQuadrant US greg(at)2ndQuadrant(dot)com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com