apache/iceberg · error · UncheckedSQLException
Failed to get lock information for %s
Error message
Failed to get lock information for %s
What it means
Thrown by JdbcLock.instanceId when the SELECT that reads the current lock instance id for the given lock type fails with a SQLException. Callers (tryLock's post-failure check, unlock) cannot determine who holds the lock, so the original SQL error is wrapped in UncheckedSQLException.
Source
Thrown at flink/v2.1/flink/src/main/java/org/apache/iceberg/flink/maintenance/api/JdbcLockFactory.java:303
return pool.run(
conn -> {
try (PreparedStatement sql = conn.prepareStatement(GET_LOCK_SQL)) {
sql.setString(1, type.key);
sql.setString(2, lockId);
try (ResultSet rs = sql.executeQuery()) {
if (rs.next()) {
return rs.getString(1);
} else {
return null;
}
}
}
});
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
throw new UncheckedInterruptedException(e, "Interrupted during unlock");
} catch (SQLException e) {
throw new UncheckedSQLException(e, "Failed to get lock information for %s", type);
}
}
}
private enum Type {
MAINTENANCE("m"),
RECOVERY("r");
private final String key;
Type(String key) {
this.key = key;
}
}
}
View on GitHub (pinned to 86d9c8fc54)
Solutions
- Read the wrapped SQLException (getCause) for the underlying SQL error
- Verify the lock table exists with the expected schema and the user has SELECT rights
- Check DB availability and connection pool health from the taskmanager
- Retry after connectivity is restored; the lock state is unknown until this query succeeds
Example fix
// before: lock table manually dropped during maintenance DROP TABLE iceberg_lock; // instanceId query fails // after: recreate lock tables (restart JdbcLockFactory.initializeLockTables) and never drop while jobs run
Defensive patterns
Strategy: retry
Validate before calling
// preflight lock table readability
try (Connection c = ds.getConnection();
ResultSet rs = c.createStatement().executeQuery(
"SELECT instance_id FROM " + lockTable + " WHERE lock_id = ?")) {
// OK
} catch (SQLException e) { alert("Cannot read lock table: " + e.getMessage()); } Try / catch
try {
triggerMaintenance();
} catch (UncheckedSQLException e) {
if (isTableMissing(e)) { recreateLockTables(); }
else if (isTransient(e)) { backoffAndRetry(); }
else { throw e; }
} Prevention
- Never drop or rename lock tables while maintenance jobs are configured
- Keep SELECT grants on the lock tables for the runtime user
- Use HA endpoints for the lock database and validate the connection pool regularly
- Add monitoring on lock-table query latency to catch timeouts early
When it happens
Trigger: The lock-info SELECT fails: connection lost, lock table dropped/renamed, SELECT privilege missing, or SQL timeout while scanning the lock table.
Common situations: DB outage or connection pool exhaustion; manual schema changes removing the lock table; permission tightening on the maintenance user; timeout under heavy DB load.
Understand the failure class
Background: Database query failed: Internal Server Error 500s wrapping SQL, Prisma, and connection failures — what to check first — this error's family across 16 libraries.
Related errors
- Failed to check the state of the lock %s
- Failed to create %s lock
- Failed to remove lock %s
- Cannot initialize JDBC table maintenance lock
- Failed to check the state of the lock %s
AI-assisted analysis of apache/iceberg@86d9c8fc54 (2026-09-12).
Data as JSON: /api/errors/e19d73d5b5a4a5cc.
Report an issue: GitHub.