github-actions[bot] commented on code in PR #68238:
URL: https://github.com/apache/doris/pull/68238#discussion_r4079138264
##########
fe/fe-core/src/main/java/org/apache/doris/datasource/paimon/PaimonMetadataOps.java:
##########
@@ -358,11 +395,38 @@ private void performDropTable(String dBName, String
tableName, boolean ifExists)
@Override
public void afterDropTable(String dbName, String tblName) {
Optional<ExternalDatabase<?>> db = dorisCatalog.getDbForReplay(dbName);
- db.ifPresent(externalDatabase ->
externalDatabase.unregisterTable(tblName));
+ try {
+ if (db.isPresent()) {
+ boolean invalidated =
db.get().unregisterTableForReplay(tblName);
Review Comment:
**[P1] Retire retained table objects when replay cannot resolve the mode-2
name**
With `lower_case_table_names=2`, `getTableForReplay` returns empty as soon
as `lowerCaseToTableName` lacks the key, even if `MetaCache` still holds the
canonical `ExternalTable` because names refresh and the object cache are
independent. Both this drop fallback and `replayRefreshTable` respond to that
miss by flushing only the Paimon SDK cache, so neither retires the old table
object. If the remote table is recreated with the same spelling, the mapping is
restored and `MetaCache.getMetaObj` reuses the previous incarnation. The new
test clears the database-name mapping and takes the unresolved-database `else`
branch, so it misses this resolved-database/lost-table-mapping case. Retire the
database's legacy table-object generation (or otherwise evict the retained
case-equivalent object) in both replay paths, and cover drop and refresh
followed by same-name recreation.
##########
fe/fe-core/src/main/java/org/apache/doris/catalog/RefreshManager.java:
##########
@@ -260,6 +265,13 @@ public void refreshTableInternal(ExternalDatabase db,
ExternalTable table, long
table.getName(), table.getId(), db.getFullName(),
db.getCatalog().getName(), updateTime);
}
+ private void invalidatePaimonCatalogForUnresolvedReplay(ExternalCatalog
catalog) {
+ if (catalog instanceof PaimonExternalCatalog) {
+ Env.getCurrentEnv().getExtMetaCacheMgr()
Review Comment:
**[P1] Keep refresh replay cache failures out of the fatal journal boundary**
`invalidateCatalogByEngine` here can propagate `CacheException`: Paimon's
`invalidateCatalogEntries` calls `PaimonTableLoader.invalidateCatalog`, which
wraps catalog/SDK failures, and `safeInvalidate` does not catch them. The other
directly escaping refresh paths changed by this patch have the same failure
mode: resolved database/table replay reaches typed `invalidateDatabase` /
`invalidate`, while catalog replay with `invalidCache=true` reaches final
catalog invalidation. These are cache-cleanup steps for already committed
`OP_REFRESH_CATALOG` / `OP_REFRESH_EXTERNAL_*` records, but any exception
escapes into `EditLog`'s generic handler, which exits the FE by default.
Contain invalidation failures for these replay-only refresh paths, as the
Paimon drop hooks do, and cover injected failures for catalog plus resolved and
unresolved database/table replay.
--
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]
