[quinnj-bot]

Postgres.cursor mishandled a batch that fails after the first one:

• Server error (division by zero, a failed cast, a statement timeout, a deadlock): the transaction the cursor opened for itself stayed open and aborted. Every later statement on the connection failed with 25P02 current transaction is aborted. DBInterface.close!(cursor) then threw expected COMMIT but PostgreSQL completed ROLLBACK. A cursor consumed by Tables.columntable(...), collect(...) or DataFrame(...) can't be closed at all, so only Postgres.rollback(conn) recovered the connection.
• Decode error (for example an infinity date in a later batch): the cursor stayed open, so a caller that kept iterating silently skipped the failed batch's rows. A failure on row 3 with fetchsize=1 gave rows [1, 2, 4, 5].

A failed first batch already closed the cursor and rolled back its transaction. fetch_portal! now does the same for later batches: it closes the portal and the cursor's statement, and rolls back a transaction the cursor opened. A transaction the caller opened is left to the caller.

cur = Postgres.cursor(conn, "SELECT 1 / (g - 3) AS x FROM generate_series(1, 5) g"; fetchsize=1)
collect(cur)                          # division by zero
DBInterface.execute(conn, "SELECT 1") # main: 25P02; now: works

Found by a differential check of Postgres.jl against psycopg 3 on PostgreSQL 16 (streaming vs buffered reads).

Verification

• New assertions in the "Cursor Streaming" testset: 6 of 10 fail on main and all pass with this change.
• Also checked against PostgreSQL 16:
  • A cursor failing inside Postgres.transaction: the block still rolls back and the connection is usable afterwards.
  • Inside a raw-SQL BEGIN: the caller's transaction stays open until their own ROLLBACK.
  • A socket closed mid-stream: transaction state is cleared, so a reconnect=true connection reconnects. Before, it refused to reconnect until the cursor was closed.
• Error rows are reported at the right position for fetchsize 1, 7, 1000 and 100000.
• Streaming and buffered reads still agree on 200k rows and on 40–50 MiB values, checked with server-side md5.
• Full local Pkg.test() (Julia 1.12.6, Docker PostgreSQL 16): 9250/9250 passed.

Review notes

I re-read the diff as a reviewer. fetch_portal! has one caller (iterate); the first batch is read in the constructor, which already handles errors. close_cursor! takes the connection lock after fetch_portal! has released it. A failure during cleanup is swallowed, so the batch error is what the caller sees; rethrow() after the nested try keeps the original exception and backtrace. Iterating the cursor after the failure returns nothing rather than reading past the lost batch.

🤖 Generated with Claude Code