[jira] Commented: (CASSANDRA-2305) Tombstoned CFs not reset after compaction

["Jeffrey Wang (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CASSANDRA-2305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13004960#comment-13004960 ] 

Jeffrey Wang commented on CASSANDRA-2305:
-----------------------------------------

For a little more info, I think this only happens when you remove an entire row. If you delete specific columns, the tombstones are handled appropriately.

> Tombstoned CFs not reset after compaction
> -----------------------------------------
>
>                 Key: CASSANDRA-2305
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-2305
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 0.7.0
>            Reporter: Jeffrey Wang
>
> From email to list:
> I was wondering if this is the expected behavior of deletes (0.7.0). Let's say I have a 1-node cluster with a single CF which has gc_grace_seconds = 0. The following sequence of operations happens (in the given order):
> insert row X with timestamp T
> delete row X with timestamp T+1
> force flush + compaction
> insert row X with timestamp T
> My understanding is that the tombstone created by the delete (and row X) will disappear with the flush + compaction which means the last insertion should show up. My experimentation, however, suggests otherwise (the last insertion does not show up).
> I believe I have traced this to the fact that the markedForDeleteAt field on the ColumnFamily does not get reset after a compaction (after gc_grace_seconds has passed); is this desirable? I think it introduces an inconsistency in how tombstoned columns work versus tombstoned CFs. Thanks.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira