prestodb/presto · error · PrestoException

ICEBERG_COMMIT_ERROR

ICEBERG_COMMIT_ERROR

Error message

Failed to acquire locks from metastore because the underlying metastore table 'HIVE_LOCKS' does not exist. This can occur when using an embedded metastore which does not support transactions. To fix this use an alternative metastore.

What it means

commit() detects that the underlying failure message contains "Table/View 'HIVE_LOCKS' does not exist" and rewraps it as ICEBERG_COMMIT_ERROR with an explanation: the metastore's transactional lock tables are missing, typical of an embedded/non-transactional metastore. The commit could not acquire HMS locks.

Source

Thrown at presto-iceberg/src/main/java/com/facebook/presto/iceberg/HiveTableOperations.java:332

                }
                else {
                    PartitionStatistics tableStats = metastore.getTableStatistics(metastoreContext, database, tableName);
                    metastore.persistTable(metastoreContext, database, tableName, table, privileges, () -> tableStats, useHMSLock ? ImmutableMap.of() : hmsEnvContext(base.metadataFileLocation()));
                }
            }
            catch (AlreadyExistsException e) {
                throw new PrestoException(HIVE_METASTORE_ERROR, format("Table already exists: %s.%s", database, tableName), e);
            }
            catch (CommitFailedException | CommitStateUnknownException e) {
                throw e;
            }
            catch (Throwable e) {
                if (e instanceof PrestoException && e.getCause() instanceof InvalidObjectException) {
                    throw new ValidationException(e, "Invalid Hive object for %s.%s", database, tableName);
                }
                if (e.getMessage() != null
                        && e.getMessage().contains("Table/View 'HIVE_LOCKS' does not exist")) {
                    throw new PrestoException(ICEBERG_COMMIT_ERROR,
                            "Failed to acquire locks from metastore because the underlying metastore "
                                    + "table 'HIVE_LOCKS' does not exist. This can occur when using an embedded metastore which does not "
                                    + "support transactions. To fix this use an alternative metastore.",
                            e);
                }
                CommitStatus commitStatus;
                if (e.getMessage() != null
                        && e.getMessage()
                        .contains(
                                "The table has been modified. The parameter value for key '"
                                        + METADATA_LOCATION_PROP
                                        + "' is")) {
                    // It's possible the HMS client incorrectly retries a successful operation, due to network
                    // issue for example, and triggers this exception. So we need double-check to make sure
                    // this is really a concurrent modification. Hitting this exception means no pending
                    // requests, if any, can succeed later, so it's safe to check status in strict mode
                    commitStatus = checkCommitStatusStrict(newMetadataLocation, metadata);
                    if (commitStatus == FAILED) {

View on GitHub (pinned to 55bb57d202)

Solutions

1. Use a real (remote, transactional) metastore with a supported database (MySQL/Postgres backed HMS schema) so HIVE_LOCKS exists.
2. Disable HMS-based locking for the catalog and use an alternative lock provider (e.g. in-process/atomic swap) if transactions are not needed.
3. If the schema exists, run Hive schematool / initSchema to create the transaction tables.

Example fix

// before (catalog properties)
iceberg.catalog.hive.hive-lock.enabled=true
// after — with embedded metastore, disable HMS lock
iceberg.catalog.hive.hive-lock.enabled=false

// before enabling HMS lock, verify transaction tables exist
// run in metastore DB: SHOW TABLES LIKE 'HIVE_LOCKS';

try { commit(); }
catch (PrestoException e) { if (e.getErrorCode() == ICEBERG_COMMIT_ERROR.toErrorCode()) { /* switch to real metastore or disable HMS lock */ } }

When it happens

Trigger: Committing to an Iceberg table whose catalog is configured with useHMSLock / transactional Hive locking (hive.support.concurrency=true, LOCK_MANAGER configured) against a metastore lacking the HIVE_LOCKS table (embedded Derby metastore).

Common situations: Local/dev setups using embedded metastore with HMS-based locking enabled (iceberg.hive-lock.enabled / hive.metastore lock configuration); test environments copying production config that enables DbLockManager.

Related errors

• Failed connecting to Hive metastore: ${addresses}
• ICEBERG_INVALID_METADATA
• Metadata location [%s] is not same as table metadata locatio
• HIVE_METASTORE_ERROR
• Invalid Hive object for %s.%s

AI-assisted analysis of prestodb/presto@55bb57d202 (2026-09-04). Data as JSON: /api/errors/fb36f1e6493ebf4d. Report an issue: GitHub.