Branimir Lambov created CASSANDRA-19764:
-------------------------------------------
Summary: Corruption can occur while a field is being added to UDT
clustering key
Key: CASSANDRA-19764
URL: https://issues.apache.org/jira/browse/CASSANDRA-19764
Project: Cassandra
Issue Type: Bug
Components: Feature/UDT
Reporter: Branimir Lambov
CASSANDRA-15938 made some improvements in how unknown components in UDTs are
treated. Unfortunately this can cause corruption as soon as more than one value
is inserted for a partition.
The problem can be easily shown by modifying the
{{FrozenUDTTest.testDivergentSchema}} test to insert two entries in the wrong
order:
{code:java}
cluster.coordinator(1).execute("insert into " + KEYSPACE + ".x (id, ck, i)
VALUES (?, " + json(1, 2) + ", ? )", ConsistencyLevel.ALL,
1, 2);
cluster.coordinator(1).execute("insert into " + KEYSPACE + ".x (id, ck, i)
VALUES (?, " + json(1, 1) + ", ? )", ConsistencyLevel.ALL,
1, 1);
{code}
after which we can get corrupted sstable state, shown as a
{code:java}
java.lang.AssertionError: Lower bound [SSTABLE_LOWER_BOUND(1) ]is bigger than
first returned value [Row: ck=1 | i=2]
{code}
exception, or results like {{[[1],[2],[2],[1]]}} or {{[[2],[1],[2]]}} for
{{select i from x WHERE id = 1}} depending on which node we use as coordinator.
Because we don't know the type of new fields and cannot properly order entries,
we need to outright reject UDT keys that are not compatible with a replica's
schema.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
