belliottsmith commented on code in PR #3967:
URL: https://github.com/apache/cassandra/pull/3967#discussion_r1993471825
##########
src/java/org/apache/cassandra/schema/SchemaKeyspace.java:
##########
@@ -140,6 +140,7 @@ private SchemaKeyspace()
+ "clustering_order text,"
+ "column_name_bytes blob,"
+ "kind text,"
+ + "unique_id int,"
Review Comment:
Perhaps I'm misunderstanding, so let's spell out the problem case so I can
understand better. Consider some table metadata that changes its columns like
so:
Epoch 1: {"pk", "ck", "v1"}
Epoch 2: {"pk", "ck", "v1", "v3"}
Epoch 3: {"pk", "ck", "v1", "v2", "v3"}
Let's assume the epoch on which we first issued uids has long since passed,
and everyone witnesses Epoch 1 just fine and assigns uids to the initial
columns consistently, but some replicas do not witness epoch 2.
If some follower assigns the uids on epoch 2, and another on epoch 3, we
would end up with
Epoch 2: {"pk":1, "ck":2, "v1":3, "v2":5, "v3":4}
Epoch 3: {"pk":1, "ck":2, "v1":3, "v2":4, "v3":5}
What stops this happening, if it isn't applied by CMS? Is there some
follower that is guaranteed to process the changes on both epochs 2 and 3, and
assign the uid, and others are guaranteed to consume this version?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
