On 11/09/2012 07:53 PM, Jeff Davis wrote:
> One problem is telling which pages are protected and which aren't. We
> can have a couple bits in the header indicating that a checksum is
> present, but it's a little disappointing to have only a few bits
> protecting a 16-bit checksum.
Given your description of option 2 I was under the impression that each
page already has a bit indicating whether or not the page is protected
by a checksum. Why do you need more bits than that?
> Also, I think that people will want to have a way to protect their old
> data somehow.
Well, given that specific set of users is not willing to go through a
rewrite of each and every page of its database, it's hard to see how we
can protect their old data better.
However, we certainly need to provide the option to go through the
rewrite for other users, who are well willing to bite that bullet.
From a users perspective, the trade-off seems to be: if you want your
old data to be covered by checksums, you need to go through such an
expensive VACUUM run that touches every page in your database.
If you don't want to or cannot do that, you can still turn on
checksumming for newly written pages. You won't get full protection and
it's hard to tell what data is protected and what not, but it's still
better than no checksumming at all. Especially for huge databases, that
might be a reasonable compromise.
One could even argue, that this just leads to a prolonged migration and
with time, the remaining VACUUM step becomes less and less frightening.
Do you see any real foot-guns or other show-stoppers for permanently
allowing that in-between-state?
Or do we have other viable options that prolong the migration and thus
spread the load better over time?
Regards
Markus Wanner