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/04/13 21:02:41 UTC

[jira] [Updated] (CASSANDRA-13430) Cleanup isIncremental/repairedAt usage

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

Blake Eggleston updated CASSANDRA-13430:
----------------------------------------
         Reviewer: Marcus Eriksson
    Fix Version/s: 4.0
           Status: Patch Available  (was: Open)

| [trunk|https://github.com/bdeggleston/cassandra/tree/13430] | [utests|https://circleci.com/gh/bdeggleston/cassandra/4] |

I ran the repair dtests locally with no issues

> Cleanup isIncremental/repairedAt usage
> --------------------------------------
>
>                 Key: CASSANDRA-13430
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-13430
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Blake Eggleston
>            Assignee: Blake Eggleston
>             Fix For: 4.0
>
>
> Post CASSANDRA-9143, there's no longer a reason to pass around {{isIncremental}} or {{repairedAt}} in streaming sessions, as well as some places in repair. The {{pendingRepair}} & {{repairedAt}} values should only be set at the beginning/finalize stages of incremental repair and just follow sstables around as they're streamed. Keeping these values with sstables also fixes an edge case where you could leak repaired data back into unrepaired if you run full and incremental repairs concurrently.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)