[
https://issues.apache.org/jira/browse/CASSANDRA-5745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13851649#comment-13851649
]
Sylvain Lebresne commented on CASSANDRA-5745:
---------------------------------------------
bq. A pretty simple tweak we could make would be to allow tombstone compactions
to include L+1 overlaps
If you meant that we'd include only L+1 overlaps that meets the criteria of
"more purgable tombstone that the threshold", i.e. that we'd basically just
make tombstone compaction better at purging tombstone, then I'm definitively
for it. That's kind of what I intended by 'add one more compaction heuristic
like we already have the "try compacting a sstable if it's has more than X%
gcable stuffs and you have nothing better to do"' (though it's definitively a
simpler thing to add that the heuristic I described) :).
I you meant we've include all L+1 overlaps no matter what, I do am worried
about the added overhead in general.
> Minor compaction tombstone-removal deadlock
> -------------------------------------------
>
> Key: CASSANDRA-5745
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5745
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Reporter: Jonathan Ellis
> Fix For: 2.0.4
>
>
> From a discussion with Axel Liljencrantz,
> If you have two SSTables that have temporally overlapping data, you can get
> lodged into a state where a compaction of SSTable A can't drop tombstones
> because SSTable B contains older data *and vice versa*. Once that's happened,
> Cassandra should be wedged into a state where CASSANDRA-4671 no longer helps
> with tombstone removal. The only way to break the wedge would be to perform a
> compaction containing both SSTable A and SSTable B.
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
