PostgreSQL Error 25P02: Current Transaction Is Aborted

PostgreSQL SQLSTATE 25P02 is in_failed_sql_transaction. Its message is usually current transaction is aborted, commands ignored until end of transaction block. This is a follow-on error: an earlier statement failed inside the open transaction, and PostgreSQL will not run later statements until the transaction is rolled back or recovered to a savepoint. The PostgreSQL error-code appendix lists 25P02 as an invalid transaction state.

Find the first error, not the repeated 25P02 message

When a client continues sending statements in the same explicit transaction after one statement fails, later statements can report 25P02 even if they are valid. Run these commands separately in the same interactive session:

BEGIN;

SELECT 1 / 0;

This first error is division-by-zero (22012). The transaction is now aborted. If you submit another statement in the same session, even a valid query reports 25P02:

SELECT 1;

Recover by rolling back the failed transaction:

ROLLBACK;

Submit each command separately for this demonstration. If a client sends all statements as one simple Query message, PostgreSQL stops processing that message at the first error, so the later query and ROLLBACK might not run. See the PostgreSQL message-flow documentation section on multiple statements in a simple query.

Check the first server error in the client output, application logs, or database logs. That error explains why the transaction failed. Repeating the later statement will not fix it. Common first errors include constraint violations, query cancellation, and lock errors; see PostgreSQL Error 57014 and Error 55P03.

Roll back the failed transaction

If the whole unit of work should be discarded, end it with ROLLBACK:

ROLLBACK;

The connection can then run statements in a new transaction. PostgreSQL runs each statement in its own implicit transaction when the client is not inside an explicit transaction, but clients and libraries may open transactions automatically. Check the transaction settings of the interface you are using; see PostgreSQL’s transaction tutorial and ROLLBACK command.

Recover to a savepoint when earlier work should remain

If the transaction created a savepoint before the failing statement, roll back only to that savepoint:

BEGIN;
UPDATE inventory SET reserved = reserved + 1 WHERE item_id = 42;
SAVEPOINT optional_step;
SELECT 1 / 0; -- example of an optional statement failing
ROLLBACK TO SAVEPOINT optional_step;
COMMIT;

ROLLBACK TO SAVEPOINT undoes work after the savepoint and makes the transaction usable again; earlier work remains pending until commit or full rollback. Without a savepoint established before the failure, roll back the entire transaction. PostgreSQL documents that rolling back to a savepoint is the way to regain control of a transaction block that was put into the aborted state by an error.

For other SQLSTATE guides, browse PostgreSQL Error Troubleshooting.