[
https://issues.apache.org/jira/browse/CASSANDRA-15069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16802281#comment-16802281
]
Pedro Gordo commented on CASSANDRA-15069:
-----------------------------------------
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: [email protected]
For additional commands, e-mail: [email protected]
