[
https://issues.apache.org/jira/browse/CASSANDRA-20318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcus Eriksson updated CASSANDRA-20318:
----------------------------------------
Status: Ready to Commit (was: Review In Progress)
+1
> Invalidate prepared statements whenever table metadata changes
> --------------------------------------------------------------
>
> Key: CASSANDRA-20318
> URL: https://issues.apache.org/jira/browse/CASSANDRA-20318
> Project: Apache Cassandra
> Issue Type: Bug
> Components: Cluster/Schema
> Reporter: Sam Tunnicliffe
> Assignee: Sam Tunnicliffe
> Priority: Normal
> Fix For: 5.x
>
> Attachments: ci_summary.html, result_details.tar.gz
>
>
> Coordinators and replicas compare epochs for table metadata during read &
> write requests and if a mismatch is detected the lagging peer is prompted to
> catch up. In the case of prepared statements, the table metadata of a select
> or modification is included in the cached CQLStatement and we have
> historically relied on logic in
> {{TableMetadata::changeAffectsPreparedStatements}} to determine whether a
> schema change should result in prepared statements being invalidated and
> re-prepared. Now any change to table metadata demands a re-preparation of
> prepared statements for the affected table or view as even a non-structural
> change will bump the epoch. Without this, prepared statements will never be
> invalidated as a result of a schema change outside of column/index
> definitions, changes to default ttl or to GC grace, even after detecting an
> epoch mismatch and catching up. In this scenario, the instance will retain
> the prepared statements it has until something does trigger an invalidation
> or the node is restarted.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
