cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oleg Anastasyev (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CASSANDRA-6025) Deleted row resurrects if was not compacted in GC Grace Timeout due to thombstone read optimization in CollactionController
Date Fri, 13 Sep 2013 13:44:51 GMT

     [ https://issues.apache.org/jira/browse/CASSANDRA-6025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Oleg Anastasyev updated CASSANDRA-6025:
---------------------------------------

    Attachment: 6025.diff

Fixed it by just deleting this condition. It seems that it is there by intention of minor
optimization.

                
> 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
>         Attachments: 6025.diff
>
>
> 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.
> {code}

--
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

Mime
View raw message