Baymine opened a new issue, #66133: URL: https://github.com/apache/doris/issues/66133
### Search before asking - [X] I had searched in the [issues](https://github.com/apache/doris/issues?q=is%3Aissue) and found no similar issues. ### Description When Hive table data files are replaced out-of-band — e.g. by an external job that only rewrites the underlying data files on HDFS/S3 without issuing an HMS DDL statement or an HMS event notification — the FE's in-memory `HMSExternalTable.updateTime` never advances. The FE SQL cache (`NereidsSqlCacheManager` / `SqlCacheContext`, via `CacheAnalyzer`) keys cache validity on `HMSExternalTable.getUpdateTime()`. Because that value only advances from HMS table parameters (`transient_lastDdlTime`) and never from the files actually observed during a scan, a stale `updateTime` lets the SQL cache keep serving result sets computed from the old files. Queries then return stale/incorrect data until the table's metadata is next refreshed by some other trigger. ### Reproduce 1. Create a Hive external table and run a cacheable query so its result is cached (SQL cache enabled). 2. Replace the table's data files out-of-band (rewrite the files on storage) without an HMS DDL/event, keeping HMS table parameters unchanged. 3. Re-run the same query — the FE serves the cached (stale) result because `updateTime` did not advance. ### Are you willing to submit PR? - [X] Yes I am 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
