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

  1. Read the wrapped SQLException (getCause) for the underlying SQL error
  2. Verify the lock table exists with the expected schema and the user has SELECT rights
  3. Check DB availability and connection pool health from the taskmanager
  4. 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

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


AI-assisted analysis of apache/iceberg@86d9c8fc54 (2026-09-12). Data as JSON: /api/errors/e19d73d5b5a4a5cc. Report an issue: GitHub.