You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Sylvain Lebresne (JIRA)" <ji...@apache.org> on 2011/07/04 16:39:21 UTC
[jira] [Commented] (CASSANDRA-2317) Column family deletion time is
not always reseted after gc_grace
[ 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