[ 
https://issues.apache.org/jira/browse/CASSANDRA-16878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17494674#comment-17494674
 ] 

Aleksey Yeschenko commented on CASSANDRA-16878:
-----------------------------------------------

bq. What do you think about merging before applying the schema change mutations?

Doesn't that just flip the issue? Now the following scenario is possible:

0. Table table1 does NOT exist
1. {{CREATE TABLE table1}} happens in memory, the schema mutation isn't written 
yet
2. Mutation m1 for table table1 validates successfully and is written to the 
commit log
3. Schema mutation for {{CREATE TABLE table1}} gets written to the commit log

If you replay these in commit log order, you won't be able to deserialize 
mutation m1, as the table will not have been created yet.

> Race in commit log replay can cause rejected mutations
> ------------------------------------------------------
>
>                 Key: CASSANDRA-16878
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-16878
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Legacy/Local Write-Read Paths
>            Reporter: Andres de la Peña
>            Assignee: Andres de la Peña
>            Priority: Normal
>             Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x
>
>          Time Spent: 3h 10m
>  Remaining Estimate: 0h
>
> We don't force order in the execution of replayed mutations and hence a 
> mutation can move ahead of or behind a schema change it relies on (e.g. 
> added/removed column), which can then cause it to be rejected because of a 
> schema mismatch.
> To fix this, we need to identify schema mutations and make sure the log 
> enforces their execution after all previous mutations have completed and 
> before anything following is started.
> Schema mutations are 
> [flushed|https://github.com/apache/cassandra/blob/cassandra-4.0.0/src/java/org/apache/cassandra/schema/SchemaKeyspace.java#L1266-L1271]
>  after being applied, so this only would be a problem if the node abruptly 
> stops before flushing the schema mutation.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

Reply via email to