PostgreSQL error: current transaction is aborted, commands ignored until end of transaction block
One query inside a transaction failed, and PostgreSQL refuses to run any further commands in that same transaction until you explicitly `ROLLBACK`. Every query after the failure will show this same error, even valid ones — you have to roll back before doing anything else.
What causes this error
PostgreSQL transactions are all-or-nothing by design. Once any statement inside a transaction fails — a constraint violation, a syntax error, a type mismatch — Postgres marks the whole transaction as aborted. Every subsequent command shows this same generic error, which can be confusing since it hides the original failure.
The Fix
-- Explicitly roll back before doing anything else
ROLLBACK;
-- Then check your logs / earlier output for the ORIGINAL error
-- that caused the abort in the first place — that's the real bug to fix.If you're using Prisma, this usually surfaces inside prisma.$transaction([...]) — Prisma already rolls back automatically on failure, so check the actual thrown error for the real cause rather than a generic aborted-transaction message from a raw query elsewhere.
Common causes / variations
- A unique constraint violation partway through a multi-step transaction
- Running raw SQL manually in a client session and not noticing an earlier query failed
- A type mismatch in one INSERT among several batched together
Related errors
See also: P2002 Unique constraint failed, syntax error at or near.
Comments
Loading comments...