LuciferYang opened a new issue, #10257: URL: https://github.com/apache/paimon/issues/10257
### Search before asking - [X] I searched in the [issues](https://github.com/apache/paimon/issues) and found nothing similar. ### Paimon version master ### Compute Engine N/A (catalog cache) ### Minimal reproduce step When the partition cache is enabled (`cache.partition.max-num > 0`), `CachingCatalog.dropDatabase(name, ignoreIfNotExists, cascade=true)` invalidates only the table cache entries it finds by iterating `tableCache.asMap().keySet()`. It never invalidates the partition cache, and its key-set enumeration also misses any table whose table cache entry has already expired while its partition cache entry is still live. A direct `dropTable` clears the partition cache through `invalidateTable`, so the cascade path is inconsistent. 1. Enable the partition cache. 2. `listPartitions(db.tbl)` so its partitions are cached. 3. `dropDatabase("db", false, true)`. 4. Recreate `db` and `db.tbl` within the TTL. 5. `listPartitions(db.tbl)` returns the old table's partitions instead of the new table's. ### What doesn't meet your expectations? Within the cache TTL, a same-name table recreated after a cascade drop is served the dropped table's partitions, because the partition cache is keyed only by `Identifier` (database + table name) with no generation marker. A later `listPartitions` returns partitions that no longer exist, so query planning can target stale partitions and produce wrong results or errors. ### Anything else? _No response_ ### Are you willing to submit a PR? - [X] I'm willing to submit a PR! -- 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]
