Agree whether both halves of a purchase commit

A purchase now spans two partitions. A owns stock; B owns orders. Decrementing stock only on A loses an item without an order. Inserting the order only on B sells an item without reserving it.

We already know local atomic commit. The new problem is getting separate participants to make the same commit-or-abort decision.

Ask whether each participant can commit

In two-phase commit, a coordinator first asks participants to prepare. Preparing means more than saying the request looks valid. Each participant performs the necessary checks, records enough durable state to honor its vote after recovery, and retains any required protection for the pending transaction.

Assume both local engines provide this prepared state and isolation is enforced separately. A prepares the stock change. B prepares the order. Each votes yes. A yes voter must not later decide to abort independently just because it gets tired of waiting.

Prepare
A and B durably promise they can commit. Their changes are not yet ordinary committed data.
Record the decision
After all required yes votes, the coordinator durably records commit.
Deliver the decision
A and B commit their prepared work and acknowledge completion.

The durable decision lets participants converge on one outcome even if delivery must be retried.

If a participant votes no, the coordinator chooses abort. If commit is recorded but only A receives it before a network failure, the outcome remains commit. B must eventually learn that same decision. The system may be temporarily unable to finish the transaction everywhere; it must not resolve the uncertainty by inventing conflicting outcomes.

Lose the coordinator at the difficult moment

Now suppose A and B have prepared, but neither knows the final decision and the coordinator is unavailable. Their retained locks or other protection may block unrelated work.

A timeout cannot tell them whether the coordinator recorded commit before disappearing. Basic two-phase commit can therefore block while the necessary decision is inaccessible. Replicating the coordinator’s decision state through a consensus protocol can improve fault tolerance, but consensus and atomic commit still solve different parts of the problem.

Nor does atomic commit alone define what concurrent readers observe across partitions. A complete transactional system must combine the decision protocol with appropriate concurrency and read rules.

Predict the impatient participant

B has voted yes. It receives no decision for five seconds. Can it safely discard the order and report abort merely because its timer expired?

Consider the other participant

No. A may already have received a durable commit decision. An independent abort at B would split the purchase. B must recover the agreed decision through the protocol or remain uncertain; an operational timeout does not authorize a contradictory transaction outcome.

The original purchase problem is now explicit: local engines prepare durable work, and a recoverable decision tells them whether to publish or discard it together.

Source: PostgreSQL 18’s prepared transactions, including the warning about long-lived prepared transactions. PostgreSQL provides participant operations; an external transaction manager coordinates their use.

Extended reference

The extended chapter preserves the original technical coverage, additional examples, and citations. The explanation above supplies the concepts needed for this page; the reference develops the specialist cases.

Find a section from the original chapter