[
https://issues.apache.org/jira/browse/CASSANDRA-8739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14306145#comment-14306145
]
Benedict commented on CASSANDRA-8739:
-------------------------------------
I assume this is another race condition problem, because we shouldn't be able
to compact any files that have had their starts moved? The only way it should
be a problem is if we abort, and then mark compacting based on the starts
during the move?
For CASSANDRA-8689 I intend to make it so we only permit markCompacting to
succeed on sstables in the live set. I'm tempted to make it only succeed if the
_exact instance_ is the one in the live set, so that if you're looking at a
stale copy of the file (i.e. one with moved starts) you fail, and reselect your
candidates. Would this solve this problem?
> Don't check for overlap with sstables that have had their start positions
> moved in LCS
> --------------------------------------------------------------------------------------
>
> Key: CASSANDRA-8739
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8739
> Project: Cassandra
> Issue Type: Bug
> Reporter: Marcus Eriksson
> Assignee: Marcus Eriksson
> Fix For: 2.1.3
>
>
> When picking compaction candidates in LCS, we check that we won't cause any
> overlap in the higher level. Problem is that we compare the files that have
> had their start positions moved meaning we can cause overlap. We need to also
> include the tmplink files when checking this.
> Note that in 2.1 overlap is not as big problem as earlier, if adding an
> sstable would cause overlap, we send it back to L0 instead, meaning we do a
> bit more compaction but we never actually have overlap.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
