[ https://issues.apache.org/jira/browse/CASSANDRA-2305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sylvain Lebresne updated CASSANDRA-2305: ---------------------------------------- Attachment: 2305_2nd_patch.patch The first patch was purging the cache when the full row is expired. But we don't remove expired tombstone from the cache. Attaching a second patch to purge the cache. This has two purposes: # avoid surprise for client getting tombstones back from query (either sstable2json or rangeSlice) even well after gc_grace and compaction has occured # reclaim some memory for row sitting in the cache for a very long time Note that this patch introduces concurrent deletes, and as such SHOULDN'T be applied to a branch that do not have CASSANDRA-1559 (0.7 and 0.8 have it). Patch is against 0.7 > Tombstoned rows not purged from cache 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 > > Attachments: 0001-Compaction-test.patch, > 0002-Invalidate-row-cache-on-compaction-purge.patch, 2305_2nd_patch.patch > > Original Estimate: 2h > Time Spent: 2h > Remaining Estimate: 0h > > 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