[
https://issues.apache.org/jira/browse/CASSANDRA-2305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13005211#comment-13005211
]
Sylvain Lebresne commented on CASSANDRA-2305:
---------------------------------------------
This will also happen if you remove all the columns inside the row (even though
you didn't issued a row deletion command).
The problem is that when you flush + compact and gcGrace has elapsed, if the
row is empty (i.e. all tombstone have been collected), the row itself is
collected. This means that when you issue the second wave of inserts, there is
no trace whatsoever of the row.
That's why you are not supposed to have a gcGrace too low and why it is highly
advised to use the current time as a timestamp. If so, the scenario above will
never happen.
Best thing we can do is probably to edit
http://wiki.apache.org/cassandra/DistributedDeletes to add that gcGrace should
be such that no insert with a timestamp lower that a delete could reach any
given node after gcGrace has elapsed.
> Tombstoned rows not purged after gcgraceseconds
> -----------------------------------------------
>
> 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
> Assignee: Sylvain Lebresne
> Priority: Minor
> Fix For: 0.7.4
>
>
> 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
