Error 25P02 signals that the current transaction is in a failed state because a prior statement raised an error.
PostgreSQL Error 25P02 (in_failed_sql_transaction) occurs when a statement fails and leaves the whole transaction in an aborted state. Issue ROLLBACK to cancel the bad transaction, then rerun corrected SQL inside a fresh BEGIN…COMMIT block to solve the problem.
PostgreSQL Error 25P02
Error 25P02, condition name in_failed_sql_transaction, appears when a statement fails inside a transaction and PostgreSQL marks the whole transaction as aborted. Every subsequent command is skipped until the session ends the transaction.
The server protects data consistency by blocking further commands in that broken transaction block.
Fixing the root cause or rolling back the transaction is required before you can issue more SQL.
The message shows up immediately after you run another query inside the same transaction where a previous statement threw any error such as unique-violation, foreign-key violation, or syntax error.
Applications that wrap many statements in AUTOCOMMIT OFF or explicit BEGIN…COMMIT blocks often surface 25P02 when they swallow the initial exception but keep sending SQL.
Leaving a session in failed-transaction mode wastes connections, hides real errors, and holds row or table locks.
Long-running aborted transactions also prevent VACUUM and autovacuum from reclaiming dead tuples, impacting performance.
Fast recovery keeps your application responsive and avoids lock contention in high-throughput systems.
.
Any statement inside the transaction that raises an exception turns the whole transaction into a failed state.
Subsequent commands then trigger 25P02.
Client libraries that ignore or only log the first error frequently continue sending queries, hitting the error repeatedly.
If a SAVEPOINT rollback is omitted after a sub-statement failure, the outer transaction remains aborted.
ETL or migration scripts processing thousands of statements without intermediate commits are prone to a single bad row leaving the rest of the batch in_failed_sql_transaction.
.
Yes. With AUTOCOMMIT ON, each statement runs in its own implicit transaction, so a failure does not affect the next command.
No. PostgreSQL ignores all commands until you issue ROLLBACK or COMMIT, so the session is effectively unusable.
Galaxy surfaces the exact failing line, shows the transaction state, and offers a quick-fix button to send ROLLBACK automatically.
Only if you roll back to the SAVEPOINT after the inner statement fails. Skipping that step leaves the entire transaction aborted.
.avif)
.avif){kind=logo}
