github-actions[bot] commented on code in PR #68196:
URL: https://github.com/apache/doris/pull/68196#discussion_r4089512865
##########
fe/fe-core/src/main/java/org/apache/doris/datasource/ExternalCatalog.java:
##########
@@ -1247,10 +1257,47 @@ public void unregisterDatabase(String dbName) {
if (LOG.isDebugEnabled()) {
LOG.debug("unregister database [{}]", dbName);
}
- if (isInitialized()) {
- metaCache.invalidate(dbName, Util.genIdByName(name, dbName));
+ // Resolve the canonical database object before removing it from the
local metadata cache.
+ // The row-count cache can outlive that object and must be invalidated
by its numeric id.
+ boolean catalogInitialized = isInitialized();
+ String resolvedLocalDbName = catalogInitialized ?
getLocalDatabaseName(dbName, true) : null;
+ String localDbName = resolvedLocalDbName == null ? dbName :
resolvedLocalDbName;
+ Optional<ExternalDatabase<? extends ExternalTable>> db =
catalogInitialized
+ ? metaCache.tryGetMetaObj(localDbName) : Optional.empty();
+ long dbId = db.map(ExternalDatabase::getId).orElseGet(() ->
Util.genIdByName(name, localDbName));
+ boolean hasCanonicalLocalIdentity = db.isPresent()
+ || resolvedLocalDbName != null && getLowerCaseDatabaseNames()
!= 0;
+ try {
+ if (hasCanonicalLocalIdentity) {
+ Env.getCurrentEnv().getExtMetaCacheMgr().invalidateDb(getId(),
dbId, localDbName);
+ } else {
+ Env.getCurrentEnv().getExtMetaCacheMgr().invalidateDb(getId(),
dbName);
Review Comment:
[P1] Widen when the canonical DB mapping has already disappeared. A names
refresh can remove `lowerCaseToDatabaseName` after the remote DROP without
evicting the resident `MixedDb` object. In mode 2, `resolvedLocalDbName` is
then null, so this branch routes the lowercase event spelling and the `finally`
hashes/removes that wrong local key; canonical schema/partition entries and the
old DB object can be reused when the name reappears. Treat an unresolved mode-2
name as an unknown scope: retire the DB-object generation and route
catalog-wide engine invalidation. Please cover a names-refreshed DROP with the
canonical object and engine entries still primed.
##########
fe/fe-core/src/main/java/org/apache/doris/datasource/CatalogMgr.java:
##########
@@ -883,15 +892,24 @@ private void
alterExternalCatalogPropsFenced(ExternalCatalog externalCatalog, Ca
Integer[] sec = {metadataRefreshIntervalSec,
metadataRefreshIntervalSec};
Env.getCurrentEnv().getRefreshManager().addToRefreshMap(catalogId,
sec);
}
- externalCatalog.modifyCatalogProps(newProps);
// The commit reset the catalog's execution context and closed its SDK
resources. Cached
// base generations and projections are bound to the replaced context;
retire them now so
// the next statement loads a generation the planning fences accept,
instead of retrying
- // against an unplannable cached generation until managed refresh.
+ // against an unplannable cached generation until managed refresh. The
properties are
+ // published before the reset's throwable cleanup, so retirement must
run either way.
Env currentEnv = Env.getCurrentEnv();
ExternalMetaCacheMgr cacheMgr = currentEnv == null ? null :
currentEnv.getExtMetaCacheMgr();
- if (cacheMgr != null) {
-
cacheMgr.onCatalogOperationalContextChanged(externalCatalog.getId());
+ try {
+ externalCatalog.modifyCatalogProps(newProps);
Review Comment:
[P1] Keep connector cleanup failures out of fatal property replay. A live
ALTER now deliberately journals after properties are published even when
reset/close throws, but an already-initialized follower replays that record
through the same `modifyCatalogProps` call here. A JDBC `closeClient`, Trino
shutdown, or similar local cleanup failure survives this `finally`, reaches
`EditLog.loadJournal`'s generic exception handler, and terminates the follower
with `System.exit(-1)`. That makes a committed metadata record capable of
killing a live follower because of local resource cleanup. During replay,
complete the required derived-state/cache transitions and log/suppress the
cleanup failure; add an `isReplay=true` throwing-close 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]
