[ https://issues.apache.org/jira/browse/CASSANDRA-2317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13059460#comment-13059460 ]
Sylvain Lebresne commented on CASSANDRA-2317: --------------------------------------------- Committed to trunk (as I agree this should really go there). bq. doesn't this mean that for a CF w/ no tombstone, we create a new deletioninfo every call to maybeReset? You're right, I've included a current.localDeletionTime == Integer.MIN_VALUE in the condition to escape early in that case. > Column family deletion time is not always reseted after gc_grace > ---------------------------------------------------------------- > > Key: CASSANDRA-2317 > URL: https://issues.apache.org/jira/browse/CASSANDRA-2317 > Project: Cassandra > Issue Type: Bug > Components: Core > Affects Versions: 0.6 > Reporter: Sylvain Lebresne > Assignee: Sylvain Lebresne > Priority: Minor > Fix For: 1.0 > > Attachments: > 0001-Add-AbstractColumnContainer-to-factor-common-parts-o.patch, > 0002-Add-unit-test.patch, > 0003-Reset-CF-and-SC-deletion-time-after-compaction.patch > > Original Estimate: 1h > Remaining Estimate: 1h > > Follow up of CASSANDRA-2305. > Reproducible (thanks to Jeffrey Wang) by: > Create a CF with gc_grace_seconds = 0 and no row cache. > Insert row X, col A with timestamp 0. > Insert row X, col B with timestamp 2. > Remove row X with timestamp 1 (expect col A to disappear, col B to stay). > Wait 1 second. > Force flush and compaction. > Insert row X, col A with timestamp 0. > Read row X, col A (see nothing). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira