[ https://issues.apache.org/jira/browse/CASSANDRA-15069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16802281#comment-16802281 ]
Pedro Gordo edited comment on CASSANDRA-15069 at 3/27/19 8:53 AM: ------------------------------------------------------------------ I have been trying to debug this but I'm stuck at the CompactionTask.runMayThrow method. I see that it's during this method execution that the new SSTable files are created, but I can't pinpoint the exact place where the data is scanned and the partition 96 is selected for the new SSTables files (generated from running garbagecollect). I wanted to see why this partition is being select for the new SSTable file when the gc_grace_seconds has already passed. If anyone would be willing to give me a hand to get past this point and find the place in the code where this criterion exists, I could investigate further and submit a patch. On the basis that this is a bug ofc, I might be missing something... was (Author: pedro_gordo): I have been trying to debug this but I'm stuck at the CompactionTask.runMayThrow method. I see that it's during this method execution that the new SSTable files are created, but I can't pinpoint the exact place where the data is scanned and the partition 96 is selected for the new SSTables files (generated from running garbagecollect). I wanted to see why this partition is being select for the new SSTable file when the gc_grace_seconds as already passed. If anyone would be willing to give me a hand to get past this point and find the place in the code where this criterion exists, I could investigate further and submit a patch. On the basis that this is a bug ofc, I might be missing something... > Tombstone/Partition not purged after gc_grace_seconds > ----------------------------------------------------- > > Key: CASSANDRA-15069 > URL: https://issues.apache.org/jira/browse/CASSANDRA-15069 > Project: Cassandra > Issue Type: Bug > Components: Local/Compaction, Local/SSTable > Reporter: Pedro Gordo > Priority: Normal > Fix For: 3.11.3 > > Attachments: schema.cql, sstables.tar > > > During a tombstone purge (reducing gc_grace_seconds to zero and running > `nodetool garbagecollect`), I noticed that when doing a dump of the SSTable, > sometimes, there are a few partitions that do not get completely purged, even > with gc_grace_seconds set to zero. I was able to replicate this in a small > test dataset, from which I have attached the SSTable files and the schema to > this ticket so that you can verify this as well. > Doing a dump of the mc-51-big-Data.db file, you'll notice the following > partition: > { > "partition" : { > "key" : [ "96" ], > "position" : 285, > "deletion_info" : { "marked_deleted" : "2019-03-14T21:31:55.244490Z", > "local_delete_time" : "2019-03-14T21:31:55Z" } > }, > "rows" : [ ] > }, > As you can see, the rows were removed correctly by the garbagecollect, but > the partition record, continues there, and never goes away. > From the client side, no data is returned, so it's good there. But regardless > of that, this partition should not be present in the SSTable file. -- This message was sent by Atlassian JIRA (v7.6.3#76005) --------------------------------------------------------------------- To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org