prestodb/presto · error · RuntimeException

Failed to acquire lock: %s

Error message

Failed to acquire lock: %s

What it means

During lock acquisition ThriftHiveMetastore polls the metastore lock state; if the lock enters a terminal non-ACQUIRED state (ABORTED, EXPIRED, etc.) it throws RuntimeException("Failed to acquire lock: <state>"). The Hive metastore's locking service refused or cancelled the lock needed for the operation (e.g. dropPartition).

Source

Thrown at presto-hive-metastore/src/main/java/com/facebook/presto/hive/metastore/thrift/ThriftHiveMetastore.java:1814

                                    // only retry on waiting for lock exception
                                    return e;
                                }
                                else {
                                    return new IllegalStateException(e.getMessage(), e);
                                }
                            })
                            .run("lock", stats.getLock().wrap(() ->
                                getMetastoreClientThenCall(metastoreContext, client -> {
                                    LockResponse response = client.checkLock(new CheckLockRequest(lockId));
                                    LockState newState = response.getState();
                                    if (newState.equals(WAITING)) {
                                        throw new WaitingForLockException("Waiting for lock.");
                                    }
                                    else if (newState.equals(ACQUIRED)) {
                                        acquired.set(true);
                                    }
                                    else {
                                        throw new RuntimeException(String.format("Failed to acquire lock: %s", newState.name()));
                                    }
                                    return null;
                                })));
                }
            }
            finally {
                if (!acquired.get()) {
                    unlock(metastoreContext, lockId);
                }
            }

            if (!acquired.get()) {
                throw new RuntimeException("Failed to acquire lock");
            }

            return lockId;
        }
        catch (TException e) {

View on GitHub (pinned to 55bb57d202)

Solutions

  1. Retry the operation — locks are often transient; ensure no other job holds a conflicting lock on the table.
  2. Increase hive.lock.numretries / lock timeout settings and metastore lock manager capacity.
  3. Check the metastore lock table for stale locks from dead sessions and clear them.
  4. Shorten the operation holding the lock, or schedule conflicting work (e.g. big partition drops) to avoid overlap.
  5. If using DB-backed lock manager, verify its connectivity and transaction health.

Example fix

// before
hive.lock.numretries=100

// after: more retries and longer wait for heavy DDL
hive.lock.numretries=1000
hive.lock.sleep.between.retries=60s
Defensive patterns

Strategy: retry

Validate before calling

// check for existing conflicting locks on the table before the operation
// query metastore lock manager (show locks / lock table API) and wait until free
while (tableIsLocked(db, table)) { Thread.sleep(1000); }

Try / catch

try {
    metastore.dropPartition(context, db, table, parts, false);
} catch (RuntimeException e) {
    if (e.getMessage() != null && e.getMessage().startsWith("Failed to acquire lock:")) {
        // wait/backoff and retry the whole operation
    } else throw e;
}

Prevention

When it happens

Trigger: Acquiring a metastore lock (lockTable/heartbeat/checkLock flow) where checkLock reports a state other than ACQUIRED or WAITING — typically ABORTED or EXPIRED — before the retry loop succeeds.

Common situations: Lock contention with another long-running transaction that caused lock expiry, metastore lock manager (in-memory or DB-backed) timing out because the operation took longer than hive.lock.numretries/timeout, another session explicitly aborted the lock, misconfigured hive.lock.check.interval.

Related errors


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