924060929 commented on code in PR #63612:
URL: https://github.com/apache/doris/pull/63612#discussion_r3302127493
##########
fe/fe-core/src/main/java/org/apache/doris/catalog/Env.java:
##########
@@ -7553,6 +7560,35 @@ public NereidsSortedPartitionsCacheManager
getSortedPartitionsCacheManager() {
return sortedPartitionsCacheManager;
}
+ public void notifyTableMetaChange(TableIf table) {
+ if (table == null) {
+ return;
+ }
+ TableMetaChange change =
+ TableMetaChange.fromTable(table);
Review Comment:
This is a valid observation about the crash window, but it does not cause
stale results in practice:
1. **Promoted master**: After crash, the new master starts with an empty
Caffeine cache (in-memory only), so no stale entries exist.
2. **Surviving followers**: They replay the metadata mutation (e.g.
`replayRenameColumn`) which updates the table schema. On next cache lookup,
`tablesOrDataChanged` detects the schema mismatch (column names changed, or
table version bumped) and invalidates the entry. The `OP_TABLE_META_CHANGE` is
a protocol-level optimization to eagerly invalidate — the lookup-time
validation is the correctness backstop.
3. **Design choice**: Making invalidation atomic with each metadata journal
entry is exactly what this PR avoids — it would require modifying dozens of
individual `replay*` paths. The decoupled `OP_TABLE_META_CHANGE` trades a tiny
crash-window (where lookup-time validation still catches staleness) for a
single, maintainable invalidation point.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
