Is InFailedSqlTransaction a PostgreSQL bug?

No. It is how PostgreSQL protects a transaction after an error: nothing else may run in it until it is rolled back. The fix is always for the earlier error.

Why does the traceback show a harmless SELECT?

Because that SELECT was simply the next statement after the one that failed. Look for the last bad query or ERROR line before it in the log.

Odoo upgrade error

Current transaction is aborted, commands ignored until end of transaction block

Last updated: November 2026

This is never the real error. An earlier SQL statement in the same transaction failed, and PostgreSQL now refuses everything until the transaction is rolled back.

This page is part of our guide on how to upgrade Odoo Community Edition. It explains what triggers the error, how to fix it by hand, and what an automated migration does about it.

The error

psycopg2.errors.InFailedSqlTransaction: current transaction is aborted, commands ignored until end of transaction block

The traceback ends in whatever statement happened to run next, which is often unrelated to the cause.

Raised by: PostgreSQL, for any statement after a failed one in the same transaction
Upgrade hops: Any
Real cause: The last bad query / ERROR before the traceback

What it means

Odoo loads each module's upgrade in one database transaction and commits after every module. When a statement fails inside a transaction, PostgreSQL marks the whole transaction as failed and rejects every later statement with this message until a ROLLBACK. If the failing statement was inside a try/except that swallowed the exception, the code carries on, and the next query is the one that crashes the upgrade.

So the traceback you see points at an innocent query. The query that actually failed is earlier in the log.

Find the real error

Odoo logs every failing statement with the prefix bad query (in odoo/sql_db.py, versions 15 to 19), followed by the PostgreSQL message. Earlier bad query lines can be harmless: scripts that try a statement inside a savepoint log one when it fails on purpose. Search the log for the last one before the crash:

grep -n "bad query" odoo-upgrade.log | tail -5

If Odoo did not log it (for example the statement ran through a different connection or a migration tool), look at the PostgreSQL server log: with the default log_min_error_statement = error it records every failing statement next to its error. That line holds the error to fix: a missing column, a duplicate key, a constraint violation and so on.

If you write migration scripts

Catching a database error without a savepoint leaves the transaction unusable. Wrap any statement that is allowed to fail in cr.savepoint(), which rolls back only that statement when it fails:

# wrong: the except hides the error, the next query fails instead
try:
    cr.execute("ALTER TABLE res_partner DROP CONSTRAINT old_constraint")
except Exception:
    pass

# right: only the failed statement is rolled back
try:
    with cr.savepoint():
        cr.execute("ALTER TABLE res_partner DROP CONSTRAINT old_constraint")
except Exception:
    _logger.warning("could not drop old_constraint", exc_info=True)

The same applies to custom modules whose pre_init_hook, post_init_hook or migration scripts run during the upgrade.

How OCU handles it

The scripts OCU generates and its runner wrap the statements that are allowed to fail (suspending constraints, removing records whose model changed) in savepoints, so one failed statement is rolled back on its own instead of poisoning the rest of the step. When a step still fails, the error OCU reports comes from the Odoo log of that step, and the full log is available for download from the migration page.

A free test migration shows whether your database runs into this or any other upgrade error before you change anything on your production server.

Frequently asked questions

Is InFailedSqlTransaction a PostgreSQL bug?: No. It is how PostgreSQL protects a transaction after an error: nothing else may run in it until it is rolled back. The fix is always for the earlier error.
Why does the traceback show a harmless SELECT?: Because that SELECT was simply the next statement after the one that failed. Look for the last bad query or ERROR line before it in the log.

Find upgrade errors before your production run

Upload a backup and run a free test migration. You get the upgraded database, the full log and every warning, with no change to your live system.

Start your free test migration