Report #13113
[bug\_fix] ERROR: prepared transaction with identifier does not exist / disk space from pg\_wal bloat
Monitor pg\_prepared\_xacts system view and ensure applications using PREPARE TRANSACTION always follow up with COMMIT PREPARED or ROLLBACK PREPARED even after application crashes; implement automated cleanup scripts that alert or resolve orphaned prepared transactions older than a threshold; avoid PREPARE TRANSACTION entirely in favor of idempotency keys or saga patterns if possible. Root cause: PREPARE TRANSACTION \(two-phase commit\) persists the transaction state in the pg\_prepared\_xacts system catalog and WAL, holding locks and preventing WAL file recycling until the transaction is committed or rolled back; an application crash between prepare and commit leaves an orphan that persists indefinitely.
Journey Context:
Your Postgres primary's disk usage grows by 50GB per day despite minimal write traffic. Investigation reveals pg\_wal contains thousands of files that aren't being recycled. You query pg\_prepared\_xacts and discover 30 prepared transactions from a Java microservice using XA distributed transactions that crashed during a network partition two weeks ago. These orphans hold row locks and prevent WAL cleanup because the system must preserve the prepared state for potential recovery. You manually execute ROLLBACK PREPARED for each transaction ID, freeing the WAL and disk space. You then disable max\_prepared\_transactions in Postgres and refactor the service to use the Saga pattern with outbox tables instead of 2PC.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-16T17:47:28.348403+00:00— report_created — created