cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrés de la Peña (JIRA) <>
Subject [jira] [Commented] (CASSANDRA-12952) AlterTableStatement propagates base table and affected MV changes inconsistently
Date Wed, 05 Jul 2017 08:36:00 GMT


Andrés de la Peña commented on CASSANDRA-12952:

Here are the patches for the affected branches and a couple of dtests:


I ran the patches on our internal CI and the failing tests seem unrelated to the patches.

The patches modify {{AlterTableStatement}} to send all the updates on the table and its materialized
views in a single schema mutation. 

The dtest [rename_column_test |]
verifies the regular working of renaming columns in the base table of a materialized view.

The dtest [rename_column_atomicity_test|]
uses a byteman script to kill the node right after the first schema update has been received,
losing the further MV updates. After this, without the patch, the node is able to start but
with a divergence between the schemas of the table and its view.

> AlterTableStatement propagates base table and affected MV changes inconsistently
> --------------------------------------------------------------------------------
>                 Key: CASSANDRA-12952
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Distributed Metadata, Materialized Views
>            Reporter: Aleksey Yeschenko
>            Assignee: Andrés de la Peña
>             Fix For: 3.0.x, 3.11.x, 4.x
> In {{AlterTableStatement}}, when renaming columns or changing their types, we also keep
track of all affected MVs - ones that also need column renames or type changes. Then in the
end we announce the migration for the table change, and afterwards, separately, one for each
affected MV.
> This creates a window in which view definitions and base table definition are not in
sync with each other. If a node fails in between receiving those pushes, it's likely to have
startup issues.
> The fix is trivial: table change and affected MV change should be pushed as a single
schema mutation.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message