PostgreSQL Error 40001

SQLSTATE

40001

Condition name

serialization_failure

Product

PostgreSQL

Versions

PostgreSQL 13 to 18

Category

Transactions & Concurrency

Last reviewed

24 October 2026

What it means

SQLSTATE 40001 means PostgreSQL rolled back a Repeatable Read or Serializable transaction because a concurrent transaction changed data it depended on; retrying the whole transaction is the documented fix.

In REPEATABLE READ and SERIALIZABLE transactions every statement sees the database as it was when the transaction started. If such a transaction tries to update, delete or lock a row that another transaction changed and committed after that point, PostgreSQL cannot apply the change without breaking that view, so it raises could not serialize access due to concurrent update. Under SERIALIZABLE, PostgreSQL also tracks what each transaction read; when a set of concurrent transactions could not have produced the same result in any serial order, one of them fails with could not serialize access due to read/write dependencies among transactions.

The documentation is explicit that applications using these isolation levels must be prepared to retry: the message text varies, but the SQLSTATE is always 40001 (serialization_failure). On the retry the transaction sees the other transaction's committed change from the start, so there is no conflict. Read-only transactions never fail with the Repeatable Read form. The default level, READ COMMITTED, does not raise these errors; it waits for the other transaction and then works on the newest row version.

The same SQLSTATE is also used when a query on a hot standby is cancelled because it conflicts with changes being replayed from the primary. That case has a different message ("canceling statement due to conflict with recovery") and different fixes, covered in the Hot Standby chapter of the documentation.

Common causes

• Two REPEATABLE READ or SERIALIZABLE transactions update the same row, and the one that commits second fails.
• A SERIALIZABLE transaction reads rows that another concurrent transaction changes, and the combination has no serial order (for example the documentation's two transactions that each insert a total computed from the other's rows).
• An application or framework sets the isolation level to SERIALIZABLE for every transaction but has no retry loop.
• Hot rows (counters, balances, stock levels) updated by many concurrent serializable transactions.
• Long queries on a hot standby that conflict with WAL replay (same SQLSTATE, different message).

Diagnose it

Read-only These queries only read the system catalogs (pg_catalog, information_schema) and statistics views such as pg_stat_activity and pg_locks. They do not change data, roles or settings, so they are safe to run first.

SELECT current_setting('transaction_isolation') AS isolation,
       current_setting('default_transaction_isolation') AS default_isolation;

SELECT r.rolname, d.datname, s.setconfig
FROM pg_db_role_setting AS s
LEFT JOIN pg_roles AS r ON r.oid = s.setrole
LEFT JOIN pg_database AS d ON d.oid = s.setdatabase;

SELECT datname, confl_snapshot, confl_lock, confl_bufferpin, confl_deadlock
FROM pg_stat_database_conflicts
ORDER BY datname;

How to fix it

Each fix is labelled with what it changes. Try read-only checks and the least invasive fix first, and test changes outside production.

BEGIN ISOLATION LEVEL READ COMMITTED;
SELECT balance FROM accounts WHERE acctnum = 11111 FOR UPDATE;
UPDATE accounts SET balance = balance - 100.00 WHERE acctnum = 11111;
COMMIT;

BEGIN ISOLATION LEVEL SERIALIZABLE READ ONLY DEFERRABLE;
SELECT class, sum(value) FROM mytab GROUP BY class;
COMMIT;

Examples

Repeatable Read: two transactions update the same row

Shown as documented in the PostgreSQL documentation (Transaction Isolation, Repeatable Read Isolation Level). This example needs a running PostgreSQL server (two concurrent sessions), which PGlite does not provide, so it was not reproduced here. If session 2 is still open when session 1 updates, session 1 waits; it fails only once session 2 commits.

-- Session 1
BEGIN ISOLATION LEVEL REPEATABLE READ;
SELECT balance FROM accounts WHERE acctnum = 11111;

-- Session 2
BEGIN;
UPDATE accounts SET balance = balance - 50.00 WHERE acctnum = 11111;
COMMIT;

-- Session 1
UPDATE accounts SET balance = balance - 100.00 WHERE acctnum = 11111;

ERROR:  could not serialize access due to concurrent update

Serializable: two transactions that each insert a total of the other's rows

Shown as documented in the PostgreSQL documentation (Transaction Isolation, Serializable Isolation Level): one transaction commits and the other is rolled back with this message. The documentation shows the ERROR line only; a server also sends a DETAIL line with an internal reason code and a HINT that the transaction might succeed if retried. This example needs a running PostgreSQL server (two concurrent sessions), which PGlite does not provide, so it was not reproduced here.

-- mytab holds (1, 10), (1, 20), (2, 100), (2, 200)

-- Session A
BEGIN ISOLATION LEVEL SERIALIZABLE;
SELECT SUM(value) FROM mytab WHERE class = 1;   -- 30
INSERT INTO mytab VALUES (2, 30);

-- Session B
BEGIN ISOLATION LEVEL SERIALIZABLE;
SELECT SUM(value) FROM mytab WHERE class = 2;   -- 300
INSERT INTO mytab VALUES (1, 300);

-- Both commit
COMMIT;

ERROR:  could not serialize access due to read/write dependencies among transactions

How to prevent it

Use REPEATABLE READ or SERIALIZABLE only where the application has a retry loop around the whole transaction, ideally in one shared helper that also handles 40P01. Make transactions short and free of side effects (emails, HTTP calls) that cannot be repeated, or perform those after the commit succeeds.

Count and log serialization failures. A steady trickle is normal under Serializable; a sudden rise usually means a new hot row, a missing index or a long transaction that overlaps many others.

Common questions

Learn more on CodeWithSQL

• Managing transactions and concurrency
• SQL transactions and ACID explained

Official documentation

• Transaction isolation
• Serialization failure handling
• SET TRANSACTION (READ ONLY DEFERRABLE)
• Hot standby: handling query conflicts

Last technically reviewed 24 October 2026; examples and diagnostics run on PostgreSQL 18.6 documentation; SQL-level parts in PGlite 0.5.11. SQL-level examples were run in PGlite (PostgreSQL compiled to WebAssembly); examples that need a running server are shown as documented in the PostgreSQL documentation.