Incident brief
No active SQL transaction
A command that only makes sense inside an open transaction block was issued with none active. PostgreSQL rejected it instead of silently ignoring it.
What lands in your log
ERROR: ROLLBACK AND CHAIN can only be used in transaction blocks
In 10 seconds
- What triggers it
- Issue ROLLBACK AND CHAIN with no transaction block open.
- Fix
- Only issue AND CHAIN variants inside an already-open transaction block (after BEGIN).
- Proof
- Reproduced on PostgreSQL 16.14 → ROLLBACK AND CHAIN with no transaction block open was rejected with SQLSTATE 25P01. The session was unaffected afterward.
Fix
What to do right now
Application-level steps for this error.
- Only issue AND CHAIN variants inside an already-open transaction block (after BEGIN).
- Plain COMMIT/ROLLBACK outside a transaction block are not an error at all, just a warning, see the premium test.
- Don't 'fix' this by unconditionally prefixing a defensive BEGIN, see the counterexample for what that can silently discard.
BEGIN;
-- ... statements ...
ROLLBACK AND CHAIN;For this error
See this error live on the server
Run these against the affected instance to confirm the diagnosis before you act.
No active SQL transaction depends on the current connection's transaction state. Confirm that state on the same connection before changing application flow.
Current transaction assignment
Read transaction state without inferring it from a pooler's connection state.
SELECT txid_current_if_assigned() AS current_xid,
current_setting('transaction_isolation') AS isolation,
current_setting('transaction_read_only') AS read_only;Why it happens
What PostgreSQL is telling you
The mechanism behind the error, grounded in the official manual, not paraphrased.
PostgreSQL 16 Documentation, ROLLBACK
Issuing ROLLBACK outside of a transaction block emits a warning and otherwise has no effect. ROLLBACK AND CHAIN outside of a transaction block is an error.Read the full section on postgresql.org →
The chained ROLLBACK with no open transaction
AND CHAIN means 'roll back, then immediately start a new transaction with the same characteristics', with no transaction open, there's nothing to roll back or chain from, so PostgreSQL rejects it outright.Confirming the session still works
COMMIT AND CHAIN was rejected outright since there was no transaction to chain from, the session itself is unaffected, so the next statement runs fine.Reproduce & verify
A real, single-session PostgreSQL reproduction
A literal transcript of SQL run against a live PostgreSQL instance in an isolated lab. The commands below are exactly what was executed.
- 1Issue ROLLBACK AND CHAIN with no transaction block open.
- 2PostgreSQL has no current transaction to chain from.
- 3SQLSTATE 25P01 is reported.
One client: issue ROLLBACK AND CHAIN with no BEGIN first.
-- No table needed for the free reproduction; the counterexample below
-- creates its own table.
SELECT 'no schema required' AS setup_note;ROLLBACK AND CHAIN;SELECT 1 AS session_still_alive;What PostgreSQL actually returned
setup_note
--------------------
no schema required
(1 row)ERROR: ROLLBACK AND CHAIN can only be used in transaction blocks session_still_alive
----------------------
1
(1 row)The manual draws a sharp line between plain ROLLBACK/COMMIT outside a transaction (a warning) and their AND CHAIN forms (an error). This was tested directly.
Without this
Above: ROLLBACK AND CHAIN with no open transaction is a real ERROR.
With this, tested
Below: plain COMMIT and ROLLBACK with no open transaction only WARN, no error, no SQLSTATE raised to the client as an exception.
- A second operational test: exact SQL, raw output, measured result, and engineer notes
- Fix that silently discards an already-open transaction's work: exact SQL, output, and verdict
- A manual-grounded production interpretation of the lab result
Card required. Cancel before day 7 and you are not charged.
Connected
Everything this error touches
Every page this SQLSTATE connects to: the concept that explains it, the runbooks that fix it, the parameters you tune to prevent it, and the sibling errors it travels with. All real cross-references. Jump straight in, or open the full interactive map.
Verification
- Last verified
- 2026-07-16 (Docker lab, PostgreSQL 16.14)
- Verification scope
- Verified against PostgreSQL 16.14 in an isolated lab environment
- Audit status
- reviewed
Went further?
Pro unlocks the second lab proof
Free page stops the bleeding. Pro adds the operational test, SQLSTATE audit, and deeper evidence, same error, more certainty.