[
https://issues.apache.org/jira/browse/CASSANDRA-17047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17718863#comment-17718863
]
Sam Tunnicliffe commented on CASSANDRA-17047:
---------------------------------------------
Not really. Until the CEP-21 stuff actually lands we shouldn't act as though it
has IMO. So if this patch is ok to merge now, then we should probably do so (I
don't have cycles to review at the moment though sorry).
> Dropping a column can break queries until the schema is fully propagated
> (TAKE 2)
> ---------------------------------------------------------------------------------
>
> Key: CASSANDRA-17047
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17047
> Project: Cassandra
> Issue Type: Bug
> Components: Cluster/Schema
> Reporter: Benjamin Lerer
> Assignee: Benjamin Lerer
> Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> With a table like:
> {code}
> CREATE TABLE ks.tbl (id int primary key, v1 int, v2 int, v3 int)
> {code}
> and we drop {{v2}}, we get this exception on the replicas which haven't seen
> the schema change:
> {code}
> ERROR [SharedPool-Worker-1] node2 2020-06-24 09:49:08,107
> AbstractLocalAwareExecutorService.java:169 - Uncaught exception on thread
> Thread[SharedPool-Worker-1,5,node2]
> java.lang.IllegalStateException: [ColumnDefinition{name=v1,
> type=org.apache.cassandra.db.marshal.Int32Type, kind=REGULAR, position=-1},
> ColumnDefinition{name=v2, type=org.apache.cassandra.db.marshal.Int32Type,
> kind=REGULAR, position=-1}, ColumnDefinition{name=v3,
> type=org.apache.cassandra.db.marshal.Int32Type, kind=REGULAR, position=-1}]
> is not a subset of [v1 v3]
> at
> org.apache.cassandra.db.Columns$Serializer.encodeBitmap(Columns.java:546)
> ~[main/:na]
> at
> org.apache.cassandra.db.Columns$Serializer.serializeSubset(Columns.java:478)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:184)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:114)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredSerializer.serialize(UnfilteredSerializer.java:102)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:132)
> ~[main/:na]
> at
> org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:87)
> ~[main/:na]
> ...
> {code}
> Note that it doesn't matter if we {{SELECT *}} or {{SELECT id, v1}}
> CASSANDRA-15899 tried to fix the problem when columns are dropped as well as
> when columns are added. Unfortunately the fix introduced an issue and had to
> be reverted in CASSANDRA-16735.
> If the scenario for ADDED columns is tricky, the original scenario for
> DROPPED columns can be solved in a safe way at the {{ColumnFilter}} level.
> By consequence, I think that we should at least solve that scenario.
> [~bdeggleston], [~samt], [~ifesdjeen] does my proposal makes sense to you?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
