You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Benjamin Lerer (Jira)" <ji...@apache.org> on 2021/10/18 17:07:00 UTC
[jira] [Updated] (CASSANDRA-17047) Dropping a column can break
queries until the schema is fully propagated (TAKE 2)
[ https://issues.apache.org/jira/browse/CASSANDRA-17047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Benjamin Lerer updated CASSANDRA-17047:
---------------------------------------
Description:
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?
was:
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 it make sense to you?
> 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
> Reporter: Benjamin Lerer
> Assignee: Benjamin Lerer
> Priority: Normal
>
> 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.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org