[fix](fe) Make newly created external catalog table immediately visible in cache#63863
Open
heguanhui wants to merge 1 commit into
Open
Conversation
…le in cache
### What problem does this PR solve?
Issue Number: close #xxx
Related PR: #xxx
Problem Summary: When creating a table in an external catalog (Iceberg/HMS/Paimon/MaxCompute) via CREATE TABLE, the new table is not immediately visible in the internal meta cache. The afterCreateTable() implementations only call resetMetaCacheNames() which clears the namesCache but does not populate the metaObjCache. As a result, operations like SHOW CREATE TABLE fail with "table does not exist" until a manual REFRESH CATALOG is executed. The same issue exists in rename table scenarios (IcebergMetadataOps.afterRenameTable and RefreshManager.replayRefreshTable rename branch) where only resetMetaCacheNames is called for the new table name.
### Release note
Newly created or renamed external catalog tables (Iceberg/HMS/Paimon/MaxCompute) are now immediately visible without requiring a manual REFRESH CATALOG.
### Check List (For Author)
- Test: Unit Test + Regression test
- FE unit test: ExternalDatabaseRegisterTableTest (6 cases covering visibility, namesCache update, idempotency, multi-table, replay, isolation)
- Regression test: external_table_p0 (Iceberg/Hive/Paimon) and external_table_p2 (MaxCompute)
- Behavior changed: No (fix only - previously broken scenario now works)
- Does this need documentation: No
Contributor
|
Thank you for your contribution to Apache Doris. Please clearly describe your PR:
|
Contributor
Author
|
run buildall |
Contributor
TPC-H: Total hot run time: 31201 ms |
Contributor
TPC-DS: Total hot run time: 171183 ms |
Contributor
FE UT Coverage ReportIncrement line coverage |
Contributor
FE Regression Coverage ReportIncrement line coverage |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
When creating a table in an external catalog (Iceberg/HMS/Paimon/MaxCompute) via
CREATE TABLE, the new table is not immediately visible in the internal meta cache. TheafterCreateTable()implementations only callresetMetaCacheNames()which clears thenamesCachebut does not populate themetaObjCache. As a result, operations likeSHOW CREATE TABLEfail with "table does not exist" until a manualREFRESH CATALOGis executed.The same issue exists in rename table scenarios (
IcebergMetadataOps.afterRenameTableandRefreshManager.replayRefreshTablerename branch) where onlyresetMetaCacheNamesis called for the new table name.Root Cause
afterCreateTable()in all 4 external catalog implementations (HiveMetadataOps, IcebergMetadataOps, PaimonMetadataOps, MaxComputeMetadataOps) only callsdb.resetMetaCacheNames(), which clears the table name list cache but does NOT load the new table object intometaObjCachegetTableNullable()→metaCache.getMetaObj(), the table object is not found → returns null → reports table does not existMetastoreEventsProcessor) already handles this correctly viaregisterExternalTableFromEvent()which callsbuildTableForInit(checkExists=false)+metaCache.updateCache(), butenable_hms_events_incremental_syncdefaults tofalseFix
registerTableFromCreate(String tblName)method toExternalDatabasethat builds the table object withcheckExists=falseand callsmetaCache.updateCache()to populate bothnamesCacheandmetaObjCacheregisterTableFromCreateinExternalCatalog.createTable(),replayCreateTable(), andrenameTable()RefreshManager.replayRefreshTable()rename branch: replacedresetMetaCacheNames()withregisterTableFromCreate(newName)IcebergMetadataOps.afterRenameTable(): replacedresetMetaCacheNames()withregisterTableFromCreate(newName)What problem does this PR solve?
Issue Number: close #xxx
Problem Summary: After CREATE TABLE in external catalogs (Iceberg/HMS/Paimon/MaxCompute), the new table is not visible in cache. Users must manually run REFRESH CATALOG before they can use the newly created table. The same issue affects rename table operations. This PR makes newly created/renamed tables immediately visible by proactively loading them into the meta cache.
Release note
Newly created or renamed external catalog tables (Iceberg/HMS/Paimon/MaxCompute) are now immediately visible without requiring a manual REFRESH CATALOG.
Check List (For Author)
ExternalDatabaseRegisterTableTest(6 cases covering visibility, namesCache update, idempotency, multi-table, replay, isolation)external_table_p0(Iceberg/Hive/Paimon) andexternal_table_p2(MaxCompute)