[jira] [Commented] (CASSANDRA-8739) Don't check for overlap with sstables that have had their start positions moved in LCS

["Benedict (JIRA)" <ji...@apache.org>]

    [ 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)