roachpb: enforce checksum optionality, add Value.EqualData method#24126
Merged
nvb merged 1 commit intocockroachdb:masterfrom Mar 21, 2018
Merged
roachpb: enforce checksum optionality, add Value.EqualData method#24126nvb merged 1 commit intocockroachdb:masterfrom
nvb merged 1 commit intocockroachdb:masterfrom
Conversation
Fixes cockroachdb#23984. Fixes cockroachdb#22636. In cockroachdb#22636 we noticed that conditional puts were not respecting the fact that Value checksums are meant to be optional. This is because they include checksums when performing the equality check between expected and existing values. This caused serious issues and forced us to roll back 75cbeb8. This was unfortunate, but the damage was contained. It demonstrated that we need to be very careful about changing checksums on values. Later, we found in cockroachdb#23984 that a path somewhere in IMPORT was forgetting to set checksums on Values. This was causing SQL operations at a much later time to fail for the same reason that 75cbeb8 caused issues. This bug will be fixed in a different change, but the fact that it exists shows how fragile the current approach is because despite the intention, checksums are absolutely not optional. This change addresses both of these problems by making checksums optional, as they were intended to be. CPut and InitPut no longer compare the checksums of the expected and existing values. Instead, they call into a new `EqualData` method, which ignores the checksum header when comparing byte values. This is a bit higher risk than most of the changes we've been accepting at this stage of the release cycle, but it would be really nice to get this change in to 2.0 so that we can stay on track with the timeline proposed in cockroachdb#22636 (comment) (although I'm not positive that the last step of the timeline is correct because I don't think we can rely on the "baked in" protection with such a low-level change). It will also save anyone who has used IMPORT already and hit cockroachdb#22636. This change should be safe from beneath Raft inconsistency for the same reason that 75cbeb8 was safe. All CPuts beneath Raft are still careful to set checksums, so we should not see any divergence in Raft state because of this error handling change. After this change, the only uses of `bytes.Equal(v1.RawBytes, v2.RawBytes)` are in tests and the `value.Equal` method. There may be an argument for making even `value.Equal` ignore the checksum header, although it isn't used outside of other `proto.Equal` methods. ``` Nathans-MacBook-Pro:cockroach$ grep -lRE 'bytes\.Equal\(.*\.RawBytes,*,.*\.RawBytes,*\)' pkg pkg/roachpb/data.pb.go pkg/storage/engine/mvcc_test.go ``` Release note: None
Member
Contributor
Author
|
I'm going to spend some time running this with the |
Contributor
|
Review status: 0 of 7 files reviewed at latest revision, all discussions resolved, some commit checks pending. Comments from Reviewable |
Contributor
Author
|
The |
Contributor
|
Confirmed that this fixes the original issue (without the fix to IMPORT). |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #23984.
Fixes #22636.
In #22636 we noticed that conditional puts were not respecting the fact
that Value checksums are meant to be optional. This is because they include
checksums when performing the equality check between expected and existing
values. This caused serious issues and forced us to roll back 75cbeb8.
This was unfortunate, but the damage was contained. It demonstrated that
we need to be very careful about changing checksums on values.
Later, we found in #23984 that a path somewhere in IMPORT was forgetting
to set checksums on Values. This was causing SQL operations at a much later
time to fail for the same reason that 75cbeb8 caused issues. This bug will
be fixed in a different change, but the fact that it exists shows how
fragile the current approach is because despite the intention, checksums
are absolutely not optional.
This change addresses both of these problems by making checksums optional,
as they were intended to be. CPut and InitPut no longer compare the checksums
of the expected and existing values. Instead, they call into a new
EqualDatamethod, which ignores the checksum header when comparing byte values.
This is a bit higher risk than most of the changes we've been accepting at
this stage of the release cycle, but it would be really nice to get this
change in to 2.0 so that we can stay on track with the timeline proposed
in #22636 (comment)
(although I'm not positive that the last step of the timeline is correct
because I don't think we can rely on the "baked in" protection with such
a low-level change). It will also save anyone who has used IMPORT already
and hit #22636.
This change should be safe from beneath Raft inconsistency for the same
reason that 75cbeb8 was safe. All CPuts beneath Raft are still careful
to set checksums, so we should not see any divergence in Raft state
because of this error handling change.
After this change, the only uses of
bytes.Equal(v1.RawBytes, v2.RawBytes)are in tests and the
value.Equalmethod. There may be an argument formaking even
value.Equalignore the checksum header, although it isn'tused outside of other
proto.Equalmethods.Release note: None