github-actions[bot] commented on code in PR #70398:
URL: https://github.com/apache/doris/pull/70398#discussion_r4547122280
##########
fe/fe-core/src/main/java/org/apache/doris/mtmv/MTMVRelationManager.java:
##########
@@ -79,6 +83,45 @@ public Set<BaseTableInfo> getMtmvsByBaseView(BaseTableInfo
table) {
return viewMTMVs.getOrDefault(table, ImmutableSet.of());
}
+ /** Only discard local rewrite plans; replay must not refresh an MV or
load external metadata. */
+ public void invalidateRewriteCaches(String catalog, String db, String
table) {
+ Set<BaseTableInfo> affected = Sets.newHashSet();
+ if (table != null) {
+ BaseTableInfo base = new BaseTableInfo(new TableNameInfo(catalog,
db, table));
Review Comment:
[P2] Preserve canonical external table names in the dependency key
With global `lower_case_table_names=1` and an external catalog overriding it
to `2`, a table such as `lake.db.Orders` keeps its canonical mixed-case name.
`MTMVPlanUtil.generateMTMVRelation` registers that exact name via
`BaseTableInfo(TableIf)`, but this `TableNameInfo` constructor applies the
global setting and changes it to `orders`. A post-commit external refresh (and
its full follower replay) reaches this callback through
`refreshTableInternal(..., false)` without a database-wide fallback, so both
dependency lookups miss the MV and leave its pre-refresh rewrite
cache/generation unchanged. Build the key from the supplied canonical names
without global SQL-name normalization. Manual `REFRESH TABLE` has a broader
fallback and does not demonstrate this failure.
##########
fe/fe-core/src/main/java/org/apache/doris/mtmv/MTMVRelationManager.java:
##########
@@ -79,6 +83,45 @@ public Set<BaseTableInfo> getMtmvsByBaseView(BaseTableInfo
table) {
return viewMTMVs.getOrDefault(table, ImmutableSet.of());
}
+ /** Only discard local rewrite plans; replay must not refresh an MV or
load external metadata. */
+ public void invalidateRewriteCaches(String catalog, String db, String
table) {
+ Set<BaseTableInfo> affected = Sets.newHashSet();
+ if (table != null) {
+ BaseTableInfo base = new BaseTableInfo(new TableNameInfo(catalog,
db, table));
+ affected.addAll(getMtmvsByBaseTable(base));
Review Comment:
[P2] Keep refreshing MVs visible to concurrent invalidation
A successful `MTMV.addTaskResult` publishes its prebuilt rewrite caches
before calling `refreshComplete`, which reaches `refreshMTMVCache` and removes
the MV from all dependency sets before adding it back. If an external
source-table refresh runs this lookup between that remove and add, it sees an
empty set and returns without calling `invalidateRewriteCache`. The MV refresh
then re-registers its dependency while retaining the pre-change plan; the
generation barrier cannot help because this invalidation never advanced it.
External metadata refresh is not serialized by the MV lock held by
`addTaskResult`. Coordinate dependency replacement with invalidation, for
example through a relation delta or an epoch check, so a registered MV cannot
disappear from an overlapping invalidation.
--
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]
