[
https://issues.apache.org/jira/browse/CASSANDRA-2039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12987149#action_12987149
]
Richard Low commented on CASSANDRA-2039:
----------------------------------------
The v2 patch does this (and supersedes the other two patches). Now the updated
LazilyCompactedRowTest passes, as do the other tests.
It now might be possible to compute the digest for LazilyCompactedRow in just
one pass through the data - the first pass is now just used to calculate
columnCount. columnCount could be excluded from the digest (I added it just
because it was there in PrecompactedRow). However, it's used by isEmpty - what
would be the impact of using estimatedColumnCount here instead? Is
estimatedColumnCount zero if and only if columnCount is zero? Or does it
matter is isEmpty sometimes returns false when it's true?
> LazilyCompactedRow doesn't add CFInfo to digest
> -----------------------------------------------
>
> Key: CASSANDRA-2039
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2039
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 0.7.0
> Reporter: Richard Low
> Priority: Minor
> Fix For: 0.8
>
> Attachments: trunk-2038-LazilyCompactedRowTest.txt,
> trunk-2038-v2.txt, trunk-2038.txt
>
>
> LazilyCompactedRow.update doesn't add the CFInfo or columnCount to the
> digest, so the hash value in the Merkle tree does not include this data.
> However, PrecompactedRow does include this. Two consequences of this are:
> * Row-level tombstones are not compared when using LazilyCompactedRow so
> could remain inconsistent
> * LazilyCompactedRow and PrecompactedRow produce different hashes of the same
> row, so if two nodes have differing in_memory_compaction_limit_in_mb values,
> rows of size in between the two limits will have different hashes so will
> always be repaired even when they are the same.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
