Report #10036
[bug\_fix] PostgreSQL current transaction is aborted, commands ignored until end of transaction block
Root cause: When any statement in a PostgreSQL transaction fails \(e.g., unique violation, check constraint\), the transaction enters an 'aborted' or 'failed' state. In this state, the server ignores all subsequent commands \(except ROLLBACK\) to maintain atomicity. Many ORMs or raw connection handlers catch the exception but don't roll back, then try to execute another query on the same connection. The fix is to immediately execute a ROLLBACK \(or ROLLBACK TO SAVEPOINT\) after catching any exception in a transaction block. In psycopg2, use conn.rollback\(\). With SQLAlchemy, ensure the session is rolled back in the except block or use context managers that auto-rollback.
Journey Context:
You have a Python service using psycopg2 that processes user registrations. The code tries to INSERT a user, and if it fails due to a unique key violation \(IntegrityError\), it catches the exception and tries to UPDATE the existing user instead. However, after the INSERT fails, all subsequent queries on that connection fail with 'current transaction is aborted, commands ignored until end of transaction block'. You debug and realize that PostgreSQL marked the transaction as aborted, but you never rolled it back. You modify the code to add conn.rollback\(\) in the except block before attempting the UPDATE, or use a SAVEPOINT before the INSERT so you can ROLLBACK TO SAVEPOINT on failure. The service now correctly handles the duplicate key case without requiring a new connection.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-16T09:43:09.115173+00:00— report_created — created