You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Oleg Anastasyev (JIRA)" <ji...@apache.org> on 2013/09/13 15:40:52 UTC
[jira] [Created] (CASSANDRA-6025) Deleted row resurrects if was not
compacted in GC Grace Timeout due to thombstone read optimization in
CollactionController
Oleg Anastasyev created CASSANDRA-6025:
------------------------------------------
Summary: Deleted row resurrects if was not compacted in GC Grace Timeout due to thombstone read optimization in CollactionController
Key: CASSANDRA-6025
URL: https://issues.apache.org/jira/browse/CASSANDRA-6025
Project: Cassandra
Issue Type: Bug
Reporter: Oleg Anastasyev
How to reproduce:
1. Insert column
2. Flush, so you'll have sstable-1
3. Delete just inserted column
4. Flush, now you have sstable-2 as well
5. Left it uncompacted for more then gc grace time or just use 0, so you dont have to wait
6. Read data form column. You'll read just deleted column
{code}
/* add the SSTables on disk */
// This sorts sstables in the order sstable-2, sstable-1
Collections.sort(view.sstables, SSTable.maxTimestampComparator);
//...
for (SSTableReader sstable : view.sstables)
{
//...
if (iter.getColumnFamily() != null)
//...
while (iter.hasNext())
{
OnDiskAtom atom = iter.next();
// the problem is here. reading atom after gc grace time
// makes this condition false. so tombstone from sstable-2
// is not placed to temp container and is just thrown away.
// On next iteration of outer for statement an original
// data inserted in step 1 from sstable-1 will be read and
// placed to temp.
if (atom.getLocalDeletionTime() >= gcBefore)
temp.addAtom(atom);
//
}
// .. so at the end of the for statemet we resolve data from temp. which
// do not have tombstone at all -> data are resurrected.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira