You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Blake Eggleston (JIRA)" <ji...@apache.org> on 2017/08/11 21:28:00 UTC

[jira] [Updated] (CASSANDRA-13758) Incremental repair sessions shouldn't be deleted if they still have sstables

     [ https://issues.apache.org/jira/browse/CASSANDRA-13758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Blake Eggleston updated CASSANDRA-13758:
----------------------------------------
    Reviewer: Marcus Eriksson
      Status: Patch Available  (was: Open)

[trunk|https://github.com/bdeggleston/cassandra/tree/13758]

[utest|https://circleci.com/gh/bdeggleston/cassandra/87]

> Incremental repair sessions shouldn't be deleted if they still have sstables
> ----------------------------------------------------------------------------
>
>                 Key: CASSANDRA-13758
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-13758
>             Project: Cassandra
>          Issue Type: Bug
>            Reporter: Blake Eggleston
>            Assignee: Blake Eggleston
>
> The incremental session cleanup doesn't verify that there are no remaining sstables marked as part of the repair before deleting it. Deleting a successful repair session which still has outstanding sstables will cause those sstables to be demoted to unrepaired, creating an inconsistency.
> This typically wouldn't be an issue, since we'd expect the sstables to long since have been promoted / demoted. However, I've seen a few ref leak issues which can cause sstables to get stuck. Those have been fixed, but we should still protect against that edge case to prevent inconsistencies caused by future (or currently unknown) bugs.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org