github-actions[bot] commented on code in PR #68196:
URL: https://github.com/apache/doris/pull/68196#discussion_r4078867351
##########
fe/fe-core/src/main/java/org/apache/doris/datasource/ExternalMetaCacheMgr.java:
##########
@@ -465,10 +470,12 @@ public void rollbackCatalogProperties(ExternalCatalog
catalog, Map<String, Strin
lifecycleLock.lock();
try {
catalog.rollBackCatalogProps(oldProperties);
+ catalog.resetToUninitialized(false);
routeCatalogEngines(catalogId, cache -> safeInvalidate(
cache, catalogId, "rollbackCatalogProperties",
() -> cache.invalidateCatalog(catalogId)));
} finally {
+ rowCountCache.invalidateCatalog(catalogId);
Review Comment:
[P1] Mirror this catalog fence on a successful property commit. The
committed path calls `modifyCatalogProps` -> `resetToUninitialized(false)`, so
only DB objects still resident in the 1,000-entry metadata cache run removal
callbacks; row-count entries for already-evicted DBs can remain in the
independent 100,000-entry cache. `onCatalogOperationalContextChanged` then
retires only engine caches. If an endpoint/credential ALTER exposes the same
DB/table names, their deterministic IDs reuse a count loaded from the old
target until expiry. This is distinct from the tentative-rollback thread and
the resident-removal scan thread: the successful path misses the cold DB scope.
Publish one catalog row-count fence after the committed reset (fresh and
replay) and add an evicted-DB endpoint-change regression.
--
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]
