cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeffrey Wang (JIRA)" <j...@apache.org>
Subject [jira] Created: (CASSANDRA-2305) Tombstoned CFs not reset after compaction
Date Thu, 10 Mar 2011 04:39:59 GMT
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

Mime
View raw message