configuration_limit_exceeded maximum number of prepared transactions reached — 53400

Symptoms

A PREPARE TRANSACTION failed because the maximum number of concurrent prepared (two-phase) transactions is already in use. PostgreSQL raises SQLSTATE 53400 (configuration_limit_exceeded).

• The cap set by max_prepared_transactions was reached.
• Common when prepared transactions are not committed/rolled back promptly.
• Often a sign of an orphaned 2PC transaction.

What the server log shows

ERROR:  maximum number of prepared transactions reached
HINT:  Increase max_prepared_transactions (currently 0).

Why PostgreSQL raises this — what the manual says

the PREPARE TRANSACTION reference (Notes):

“If you have not set up an external transaction manager to track prepared transactions and ensure they get closed out promptly, it is best to keep the prepared-transaction feature disabled by setting max_prepared_transactions to zero.”

Two-phase commit reserves slots bounded by max_prepared_transactions. When all slots are occupied (often by transactions left prepared but not finalized), new PREPARE TRANSACTION calls fail with 53400.

Common causes

• max_prepared_transactions set to 0 or too low.
• Orphaned prepared transactions never committed/rolled back.
• A transaction manager leaking 2PC transactions.

Relevant GUC parameters

How to fix it

1. Raise max_prepared_transactions (requires restart) for genuine 2PC workloads.
2. Find and resolve orphans: SELECT * FROM pg_prepared_xacts; then COMMIT/ROLLBACK PREPARED.
3. Fix the transaction manager so it finalizes prepared transactions.

Diagnostic query

SELECT gid, prepared, owner, database FROM pg_prepared_xacts ORDER BY prepared;

Long-lived rows here indicate orphaned 2PC transactions holding slots (and locks/WAL).

Related & next steps

• SQLSTATE 53400 — Configuration Limit Exceeded (full reference)
• Message: temporary file size exceeds temp_file_limit
• Glossary: Two-phase commit

Reference: PostgreSQL 18 — PREPARE TRANSACTION.