[jira] Commented: (CASSANDRA-2039) LazilyCompactedRow doesn't add CFInfo to digest

["Jonathan Ellis (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CASSANDRA-2039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12991050#comment-12991050 ] 

Jonathan Ellis commented on CASSANDRA-2039:
-------------------------------------------

Committed v2.  Thanks!

bq. what would be the impact of using estimatedColumnCount here instead

It would break the part of CompactionIterator that leaves out rows with no columns from the new SSTable.  "estimated" is the maximum possible number of columns in the new row, so it's ok to use it in the bloom filter, but not in the "is this row empty post-merge" check.

> 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.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira