stephenafamo / bob / 29180907558

48%

main: 48%

Pull #737

github

fix: close sql.Rows in QueryStmt to prevent connection pool leak

QueryStmt.One passed the rows from stmt.QueryContext to scan.OneFromRows,
which by contract does not close caller-owned rows, and never closed them
itself. Since One reads a single row and never exhausts the result set,
database/sql cannot auto-release the connection: every prepared One call
permanently held a pool connection until PostgreSQL rejected new ones
("sorry, too many clients already", 53300).

- One: close the rows as soon as scan.OneFromRows returns, before the
  extra loaders run (matching the non-prepared exec path); a close error
  is returned if scanning itself succeeded
- All: the happy path exhausts the rows, but a scan error mid-iteration
  leaked them — now closed explicitly on every path
- Cursor: rows ownership moves to the returned cursor, but they leaked
  when scan.CursorFromRows itself failed — now closed on that error path
- stmt_test.go: regression tests with a fake Preparer/Rows that records
  Close; all four fail without the fix

Reproduced on every released version (verified on v0.42.0 and main)
against PostgreSQL 17.

6 of 12 new or added lines in 1 file covered. (50.0%)

11921 of 24865 relevant lines covered (47.94%)

727.47 hits per line