Search first

Looks like the same root cause as the downstream report quarkusio/quarkus#44042 ("jdbc leak after running liquibase … 18 ResultSet(s) and 0 Statement(s)"). I couldn't find an issue filed against Liquibase itself for the actual cause, hence this report.

Environment

• Liquibase version: 4.33.0 — but the offending code is unchanged on master and in the latest release v5.0.3.
• Database / driver: MariaDB 11.4 via MySQL Connector/J 9.2.0 (the leak is driver-independent; see below).
• Operating mode: update / migration (the snapshot taken for preconditions / changeSetExecuted).

Description

liquibase.snapshot.ResultSetCache.extract(ResultSet, boolean) closes only the ResultSet, never the Statement that produced it:

// liquibase-standard/.../snapshot/ResultSetCache.java  (master, also 4.33.0)
protected List<CachedRow> extract(ResultSet resultSet, final boolean informixIndexTrimHint) throws SQLException {
    ...
    } finally {
        JdbcUtil.closeResultSet(resultSet);   // <-- ResultSet only; the owning Statement is leaked
    }
}

Several JdbcDatabaseSnapshot paths feed this method a ResultSet obtained directly from a DatabaseMetaData call, passed inline with no reference kept to its Statement:

• extract(databaseMetaData.getColumns(...)) — JdbcDatabaseSnapshot.java:501
• extract(databaseMetaData.getImportedKeys(...)) — :877
• extract(databaseMetaData.getTables(...)) — :1243, :1263, :1352, :1407, :1423
• extract(databaseMetaData.getPrimaryKeys(...))

Per the JDBC contract, closing a ResultSet does not close its Statement. Many drivers (e.g. MySQL Connector/J) implement DatabaseMetaData.getXxx() by creating an internal Statement and registering it with the connection. After extract() returns, that Statement stays registered/open until the connection is closed.

The sibling method executeAndExtract (same file, ~line 255) handles this correctly:

} finally {
    JdbcUtil.close(resultSet, statement);   // closes BOTH
}

Actual behavior

After a snapshot, the connection carries one or more open driver Statements (the metadata statements). Connection pools that track or validate open statements on return therefore report a leak — for example, Agroal's leak detector fires, or any pool that asserts "no open statements on return" emits a recurring "statements are not closed" warning once per migration — even though every ResultSet was closed.

Expected behavior

extract(ResultSet, boolean) should close the owning Statement as well — e.g. JdbcUtil.close(resultSet, resultSet.getStatement()) — mirroring executeAndExtract, so no driver statement is leaked.

Steps to reproduce

1. Run liquibase update against a MySQL/MariaDB database using MySQL Connector/J.
2. Wrap the JDBC connection in a pool that asserts no statements remain open on return (Agroal leak detection, or any pool tracking Statements).
3. Observe leaked Statement(s) reported after the snapshot/precondition phase, even though all ResultSets are closed.

Suggested fix

In ResultSetCache.extract(ResultSet, boolean), capture and close the statement:

} finally {
    JdbcUtil.close(resultSet, resultSet.getStatement());
}

(ResultSet.getStatement() may return null for some metadata result sets; JdbcUtil.close already null-checks.)