[ https://issues.apache.org/jira/browse/CASSANDRA-16878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17485595#comment-17485595 ]
Berenguer Blasi commented on CASSANDRA-16878: --------------------------------------------- LGMT +1. I am only weary of the jvm repair test failure on j8/trunk but it could well be just the current noise on trunk. > 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: 2h 40m > 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