PostgreSQL: force wire-level BEGIN when starting a transaction

[ryudoawaru]

Problem

On PostgreSQL, begin_db_transaction ends up calling Connection#setAutoCommit(false) — but in pgjdbc that only flips a client-side flag. The actual BEGIN is deferred and piggybacked onto the next statement sent (see pgjdbc's QueryExecutorImpl#sendQueryPreamble).

Rails 7.1+ transactions are lazy on their side too: materialize_transactions calls begin_db_transaction and expects a transaction to actually be open on the server afterwards. Under AR-JDBC that materialization was a wire-level no-op — the server session stays IDLE until the next query, so anything that inspects the raw transaction state right after materialization (e.g. Rails' own adapter_test.rb via raw_transaction_open?) sees no transaction.

Fix

After setAutoCommit(false) (and setting isolation, when given), issue a no-op SELECT 1. pgjdbc prepends its deferred BEGIN to it in the same round-trip, so the cost matches the pg gem's exec("BEGIN") — one round-trip, just moved from the first in-transaction query to begin_db_transaction where AR expects it.

Includes a test that asserts the server-side transaction state is OPEN right after begin_db_transaction (it reports IDLE without the fix).

Verification

Environment: JRuby 9.4.14.0, PostgreSQL 18.4, pgjdbc 42.7.11, macOS.

• rake test_postgresql: 306 tests, 0 failures, 0 errors (includes the new test; fails without the patch)
• Rails suite (rails:test_postgresql, AR 7-2-stable), on top of 72-stable + Expose PG-compatible status/transaction_status/async_exec on the JDBC connection (+ CI Postgres 14) #1220:
  • test/cases/adapter_test.rb: 69 runs, 0 failures, 0 errors — the 4 remaining failures there (assert raw_transaction_open? right after materialize_transactions, lines 533/543/553/577) are exactly what this patch fixes
  • same with PREPARED_STATEMENTS=false: 67 runs, 0 failures, 0 errors
  • test/cases/transactions_test.rb: 105 runs, 0 failures, 0 errors

Related: #1173, #1218, #1220.

🤖 Generated with Claude Code

[headius]

Looks simple enough and good to note that it has no more overhead than the equivalent exec("BEGIN") (I immediately had a concern about the additional round-trip).

Approved by me but would be good to get input from the other active PG contributors @skunkworker @JesseChavez.

[ryudoawaru]

A note on the failing Rails-suite checks — they are inherited from 72-stable, not introduced here.

The Rails Tests (Postgres) jobs have been red on 72-stable for every recent push, well before this PR:

• Jun 13 run (pre-Fix COMMIT/ROLLBACK/savepoint retry data-loss; harden MySQL connection-loss detection #1218/Fix PostgreSQL server-side connection leak on failed establishment (too many clients) #1219): both PS modes died mid-suite with FATAL: sorry, too many clients already
• Jun 27 run (current 72-stable HEAD, i.e. this PR's merge base): PS=true again crashed with too many clients before finishing; PS=false was cancelled by fail-fast

On this PR, the PS=true job actually completes the full suite for the first time in a while — 9481 runs, 43 failures, 74 errors (log). Those break down as:

• ~20 ActiveRecord::AdapterConnectionTest failures/errors: Rails' raw_transaction_open? test helper pokes MRI's PG::Connection API (transaction_status, PG::PQTRANS_*), which doesn't exist on the JDBC raw connection. Expose PG-compatible status/transaction_status/async_exec on the JDBC connection (+ CI Postgres 14) #1220 adds exactly those shims — locally, 72-stable + Expose PG-compatible status/transaction_status/async_exec on the JDBC connection (+ CI Postgres 14) #1220 + this patch runs test/cases/adapter_test.rb at 0 failures, 0 errors in both PS modes (69/67 runs), and test/cases/transactions_test.rb at 105 runs, 0F/0E. These entries should disappear once Expose PG-compatible status/transaction_status/async_exec on the JDBC connection (+ CI Postgres 14) #1220 lands.
• The remaining ~90 are the pre-existing 72-stable long tail (composite PK, hstore, explain, deferred constraints, …), unrelated to transactions.

The PS=false job died ~2 minutes in from connection-pool exhaustion, the same long-standing issue as the too many clients crashes above.

The ARJDBC Tests (Postgres) jobs (all 4 combinations) are green, including the new server-side-transaction-state test from this PR.

[headius]

Thank you @ryudoawaru! I will talk with other contributors and see about getting some releases out. Do you have other fixes coming?

[ryudoawaru]

Thanks for merging! Two things I'm looking at next: forward-porting this fix to master, and #1212 — I've tracked down the root cause with a reproduction and posted the analysis there. Let me know if something else has priority for the releases.