[ https://issues.apache.org/jira/browse/CASSANDRA-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sylvain Lebresne updated CASSANDRA-2211: ---------------------------------------- Attachment: 0001-2211-v3.patch +1 on the patch. I'm just attaching a v3 that simply use getDefaultGcBefore() throughout CompactionManager (to make things cleaner) Sadly, this is not the only place where we echo data wrongfully, cf. CASSANDRA-2216 > Cleanup can create sstables whose contents do not match their advertised > version > -------------------------------------------------------------------------------- > > Key: CASSANDRA-2211 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2211 > Project: Cassandra > Issue Type: Bug > Affects Versions: 0.7.1 > Reporter: Jonathan Ellis > Assignee: Jonathan Ellis > Fix For: 0.7.3 > > Attachments: 0001-2211-v3.patch, 2211-v2.txt, 2211.txt > > Original Estimate: 4h > Remaining Estimate: 4h > > Since cleanup switched to per-sstable operation (CASSANDRA-1916), the main > loop looks like this: > {code} > if (Range.isTokenInRanges(row.getKey().token, ranges)) > { > writer = maybeCreateWriter(sstable, > compactionFileLocation, expectedBloomFilterSize, writer); > writer.append(new EchoedRow(row)); > totalkeysWritten++; > } > else > { > while (row.hasNext()) > { > IColumn column = row.next(); > if (indexedColumns.contains(column.name())) > Table.cleanupIndexEntry(cfs, > row.getKey().key, column); > } > } > {code} > ... that is, rows that haven't changed we copy to the new sstable without > deserializing, with EchoedRow. But, the new sstable is created with > CURRENT_VERSION which may not be what the old data consisted of. > (This could cause symptoms similar to CASSANDRA-2195 but I do not think it is > the cause of that bug; IIRC the cluster in question there was not upgraded > from an older Cassandra.) -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira