Connection of one in-process transaction being handed to a separate transaction, causing corruption

Version: postgres@3.4.7 · Node 24 · PostgreSQL 16 (AWS Aurora)

---

Summary

We observed one connection being used by two sql.begin() transactions,
and that second transaction's COMMIT then committed the first transaction's partial, unfinished writes

What we run

One pool (max: 5) shared by several concurrent sql.begin() workloads:

• a long-lived insert transaction that pipelines a few thousand INSERTs,
  then a single final UPDATE marker, all in one sql.begin;
• a concurrent short purge transaction (a DELETE within sql.begin);
• occasional table scans done in transaction snapshots

Options: max_lifetime 300–600s (randomized), idle_timeout: 60, TLS on, over a network
where connections can half-close. (We can't say whether the pool was saturated at the moment
of the collision; we only know two specific transactions, the writer and the purge, ended up
sharing one connection.)

Evidence (from the PostgreSQL server log)

Backend 74671 was in the middle of an insert transaction:

19:00:28 [74671]:LOG:  AUDIT: SESSION,1366,1,WRITE,INSERT,,,"INSERT INTO "
19:00:29 [74671]:LOG:  AUDIT: SESSION,1367,1,WRITE,INSERT,,,"INSERT INTO "

Then on that same backend:

19:00:29  [74671] WARNING:  there is already a transaction in progress   (BeginTransactionBlock)

Corresponding exactly to server log lines indicating the purger was executing its transaction:

2026-08-29T19:00:29.52707903Z  | INFO | Purging PG changes before 724at0ueo ...
2026-08-29T19:00:29.528707661Z | WARN | {"level":"WARN","pid":27,"worker":"change-streamer","workerIndex":0,"severity":"WARNING","code":"25001","message":"pg notice","routine":"BeginTransactionBlock"}
2026-08-29T19:00:29.616657299Z | INFO | Purged 6334 PG changes before 724at0ueo (89.49 ms)

(The DELETE statements from the purger are wrapped in a CTE and thus is filtered from audit logs as "reads")

After that WARNING, backend 74671 logged nothing further except a clean disconnection:

19:01:30  [74671] LOG:  disconnection: session time: 0:05:11.707 ... user=... database=...

Note: a plain disconnection, not a FATAL, not an idle-in-transaction termination, not a rollback.

Database state

1. The INSERTs were committed, but without the final UPDATE (of a different table) that the code ensures
2. The purger's delete was also committed.
3. 74671 closed with a clean disconnection even though the tx of [1] had not been committed

If the backend disconnected while a transaction is still open, the inserter's rows
would have been rolled back. They weren't. So at disconnect time 74671 held
no open transaction: its server-side transaction had already been
committed. But the inserter never issued that COMMIT. The only other operation on
74671 was the purge sql.begin(), whose BEGIN is the 25001 above — its COMMIT
persisted both the purge's changes and the insert transaction's partial changes.

Reproduction

We were not able to reproduce this synthetically on postgres@3.4.7 (a small pool
saturated with concurrent writer/purge/reader sql.begin() transactions, plus connection
recycling and backend-termination storms all held atomicity). It appears to require a
specific pool-state/timing (possibly Aurora- or half-close-specific) we couldn't force.
The server-log evidence above is from production.

Questions

1. With #274 fixed in 3.4.7, are there remaining paths where a connection still inside one
   sql.begin() transaction can be handed to a second sql.begin(), so that the second's
   BEGIN/COMMIT operate on the first's open transaction?
2. Is a 25001 from BeginTransactionBlock on a pooled sql.begin() ever expected, or is
   it always a connection-state desync?
3. Is this the same underlying cause as #827 (sql.begin() hanging under similar load)?

Our mitigation

We're moving the writer loop and the purge onto separate postgres() client instances,
each with max: 1, so the two workloads live in different in-memory pools and this
connection-sharing cannot occur. Flagging the driver behavior in case it points at a
residual bug others hit.

Start by reading the transaction and pool connection-lifecycle paths behind sql.begin(), then compare the behavior described here with fixes in #274 and the hanging scenario in #827. Investigate how a connection can be returned while a transaction remains open and whether PostgreSQL warning 25001 is handled. Done means establishing the cause or ruling out the proposed handoff, ideally with a regression test or a documented explanation.