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
- Retry the operation — locks are often transient; ensure no other job holds a conflicting lock on the table.
- Increase hive.lock.numretries / lock timeout settings and metastore lock manager capacity.
- Check the metastore lock table for stale locks from dead sessions and clear them.
- Shorten the operation holding the lock, or schedule conflicting work (e.g. big partition drops) to avoid overlap.
- 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
- Raise lock retry counts and sleep intervals for long DDL.
- Avoid overlapping heavy DDL/DML on the same Hive table.
- Monitor and clean stale metastore locks from dead sessions.
- Heartbeat long-running transactions holding locks.
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
- Failed to acquire lock
- HIVE_PARTITION_DROPPED_DURING_QUERY
- HIVE_PARTITION_DROPPED_DURING_QUERY
- HIVE_INVALID_METADATA
- NOT_SUPPORTED
AI-assisted analysis of prestodb/presto@55bb57d202 (2026-09-04).
Data as JSON: /api/errors/208adb47536bbb36.
Report an issue: GitHub.