geyanggang opened a new issue, #13020: URL: https://github.com/apache/gravitino/issues/13020
### Version main branch ### Describe what's wrong When altering a Hive-catalog table with only property or comment changes, Gravitino calls the Hive Metastore alter_table without an EnvironmentContext. The metastore then recomputes table statistics, which forces it to access the table's storage location (for example a getFileInfo call against the HDFS NameNode). For a property-only or comment-only change this filesystem access is unnecessary. If the underlying filesystem is slow or unavailable (for example the NameNode is down), a lightweight alter can hang for minutes on the server side, well beyond typical client or gateway timeouts, even though no data is being changed. ### Error message and/or stacktrace On the client the request eventually fails via a proxy/gateway timeout (e.g. HTTP 502), while the server-side alter_table call keeps blocking. Representative server-side sequence: ``` INFO HiveCatalogOperations - Received alter table request: <catalog>.<db>.<table> DEBUG loading ThriftHiveMetastore$alter_table_with_environment_context_args WARN LockManager - Thread ... holds the lock node <table> for more than 30s ... WARN LockManager - Thread ... holds the lock node <table> for more than 30s ... INFO HiveCatalogOperations - Altered Hive table <table> in Hive Metastore # ~200s later ``` The metastore thread is blocked on repeated HDFS getFileInfo retries against the NameNode during the stats update. ### How to reproduce 1. Gravitino version: main branch. 2. Create a Hive-catalog table. 3. Make the table's storage location point to a slow or unreachable filesystem (e.g. an HDFS NameNode that is down). 4. Issue an ALTER TABLE ... SET (...) (property-only) change. 5. The alter_table call blocks for a long time while the metastore updates statistics and accesses the location. ### Additional context The fix should instruct the metastore to skip statistics recomputation for property-only and comment-only alters (via DO_NOT_UPDATE_STATS), so it does not access the storage location. Column changes and renames should keep the current behavior. -- 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]
