https://www.postgresscripts.com/tags/two-phase-commit/Recent content in Two-Phase Commit on Postgres ScriptsHugo -- gohugo.ioenPostgresScripts.comFri, 19 Jun 2026 00:00:00 +0000https://www.postgresscripts.com/post/track-two-phase-commit-state-with-pg-prepared-xacts/Fri, 19 Jun 2026 00:00:00 +0000https://www.postgresscripts.com/post/track-two-phase-commit-state-with-pg-prepared-xacts/ <h2 id="track-two-phase-commit-state-with-pg_prepared_xacts">Track Two-Phase Commit State with pg_prepared_xacts</h2> <p>A prepared transaction that never gets committed or rolled back is one of the quieter ways a PostgreSQL database degrades. It keeps holding locks, it pins the transaction-ID horizon so <code>VACUUM</code> cannot reclaim dead rows, and nothing in normal monitoring screams about it. Left long enough it can drive the cluster toward a transaction-ID wraparound shutdown.</p> <script async src="https://pagead2.googlesyndication.com/pagead/js/adsbygoogle.js?client=ca-pub-1012089347386563" crossorigin="anonymous"></script> <ins class="adsbygoogle" style="display:block" data-ad-client="ca-pub-1012089347386563" data-ad-slot="7945792173" data-ad-format="auto" data-full-width-responsive="true"></ins> <script> (adsbygoogle = window.adsbygoogle || []).push({}); </script> <h2 id="purpose-and-overview">Purpose and Overview</h2> <p>Two-phase commit (2PC) splits a commit into two steps so an external coordinator can commit the same logical transaction across several resources atomically. In PostgreSQL the first step is <code>PREPARE TRANSACTION 'gid'</code>, which writes the transaction's state to disk and assigns it a global identifier. The transaction is now durable but undecided: it survives a server restart and waits for a later <code>COMMIT PREPARED 'gid'</code> or <code>ROLLBACK PREPARED 'gid'</code>, possibly from a different session.</p>