Preparing before the common decision
A transaction spanning resources cannot infer everyone’s completion from one participant. Two-phase commit obtains participants’ preparedness before the coordinator distributes the resulting decision.
Prepared does not mean that transaction effects are already committed. PostgreSQL exposes PREPARE TRANSACTION, COMMIT PREPARED, and ROLLBACK PREPARED as separate operations for an external transaction manager.
Prepared state needs recovery and eventual resolution
A prepared PostgreSQL transaction is detached from its original session and can later be resolved from another session by identifier. Recoverable state lets processing continue after a database restart rather than depending only on a client variable.
Preparation is not a free pause: locks remain held, and prolonged prepared transactions can interfere with VACUUM. The external manager must track and resolve them promptly instead of treating the feature as an indefinite resource archive.
Failures can leave participants unable to decide
Classic two-phase commit can block after coordinator failure: a prepared participant lacking the decision cannot independently choose an incompatible outcome. Gray and Lamport analyze this uncertainty as an availability limitation.
Recovery must preserve agreement while enabling eventual progress under appropriate conditions. Replicating decision-making requires additional protocol machinery. A shorter timeout alone cannot remove uncertainty in a prepared transaction.