[
https://issues.apache.org/jira/browse/CASSANDRA-2305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13005228#comment-13005228
]
Jonathan Ellis commented on CASSANDRA-2305:
-------------------------------------------
bq. 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 what's supposed to happen, but Jeffrey is saying that is NOT what he
observes.
> 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
