[
https://issues.apache.org/jira/browse/CASSANDRA-17530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17637345#comment-17637345
]
Michael Semb Wever edited comment on CASSANDRA-17530 at 11/22/22 4:02 PM:
--------------------------------------------------------------------------
bq. I don't think the bug didn't make it into any release, so was there any
change to note?
Was it not in {{4.1-alpha1}} ? (or have i misunderstood the since field field?)
was (Author: michaelsembwever):
bq. I don't think the bug didn't make it into any release, so was there any
change to note?
Was it not in {{4.1-alpha`}} ? (or have i misunderstood the since field field?)
> Paxos v2 Linearizability Violation
> ----------------------------------
>
> Key: CASSANDRA-17530
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17530
> Project: Cassandra
> Issue Type: Bug
> Components: Consistency/Coordination
> Reporter: Benedict Elliott Smith
> Assignee: Benedict Elliott Smith
> Priority: Normal
> Fix For: 4.1-beta1, 4.1, 4.2
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The version of Paxos introduced recently had a subtle mistake that
> introduced a linearizability flaw that has been detected by the simulator,
> and also a flaw with the simulator has been found that may erroneously report
> a linearizability violation.
> The true linearizability fault is quite simple: fast read permissions were
> erroneously being escalated to promises when an incomplete proposal was
> discovered. This was likely due in part to the naming of the state
> {{FOUND_INCOMPLETE_ACCEPTED}} which does not communicate that the ballot will
> be used to re-propose this proposal using the promises we have obtained. The
> fix is to yield {{SUPERSEDED}} if {{!haveOnlyPromises}}.
> The false linearizability fault was triggered when two different competing
> incomplete proposals were reproposed multiple times, with the winning
> proposal being the one with the lower original ballot, and the proposal with
> the higher ballot having been successfully proposed to a majority of nodes
> but across multiple different ballots (so that no single ballot reached a
> majority), while the most recently successful ballot (at a minority) was the
> older original ballot. The range movement validation logic looked only at the
> original ballot, and since it saw the higher original ballot as having
> reached a majority perceived that it should have become persistent, when in
> fact the older ballot did so.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
