Subject: External Catalog Metadata Persistence Issue after Upgrading from v3.3 to v4.0.5 Description: I have recently upgraded my StarRocks cluster from v3.3 to v4.0.5 following the standard rolling upgrade procedure (FE by FE, from lower to higher versions). After the upgrade, I encountered a persistent metadata inconsistency issue with a SQL Server JDBC Catalog. The Problem: Even after deleting or renaming a table in the source SQL Server database, the StarRocks FE still retains the old metadata for that table. •

SHOW TABLES

and

SHOW CREATE TABLE

still return the old schema (which appears to be a "ghost" record from a previous version). • Creating a new table with the same name in SQL Server results in a "merged" or "duplicate" column schema in StarRocks (e.g., seeing two different types for the same column ID). • Dropping and recreating the Catalog with the same name does not clear these "ghost" records from the FE's internal metadata. Environment: • StarRocks Version: upgraded from 3.3.x to 4.0.5 • Catalog Type: JDBC Catalog (SQL Server) • FE Deployment: Multi-FE HA setup Questions: Is there a specific command in v4.0.x to force-purge the persistent metadata cache in BDBJE for External Catalogs? 1. Why does

DROP CATALOG

followed by

CREATE CATALOG

(with the same name) still recover orphaned table metadata from the previous version? 2. Aside from restarting the FE nodes, is there a way to manually invalidate the Metadata Manager's internal image for a specific external table?