2PC: discussion in comp.arch

From Bill Todd's post:

This is the simple 'two-phase commit, presumed-abort' mechanism. It has no
problems guaranteeing distributed consistency, but does suffer from the
problem that if the coordinator *never* recovers some of the other nodes may
be left 'in doubt' about the fate of the transaction. In practice, with
replicated data 'never' recovering is virtually impossible, but just waiting
for some human to replace failed hardware can stall things enough that a
more complex 'three-phase commit' model exists where nodes need not wait for
the coordinator to recover. Another manner in which that issue is addressed
is by having a 'back-up' coordinator to which coordination responsibility
can be transferred; a third is by having a robust coordinator - e.g., whose
storage can be 'failed over' to another separate system which can continue
operation.

This is exactly what some of us have been saying here. As long as the
co-ordinator is capable of recovering, there is no danger of
"in-doubt" transactions stalling a subordinate indefinitely.

While I'm not sure if any database system implements 3PC, certainly
2PC-PA is implemented by most database vendors (and is part of the XA
standard). Presumed Abort (PA) is preferred to Presumed Commit (PC)
because PA involves less log sync operations for the "common case" of
read-only transactions. 2PC certainly has various real-world
applications, as with the integration of message-queueing systems.

Alternatively, if there is a plan to support serious federated
capabilities within pgsql (by expanding the current dblink prototype
for instance) the issue of 2PC will come into play if pgsql supports
remote write operations.

Anyways, this is all moot if integration with enterprise transaction
systems is not an important goal of pgsql. If there is no explicit
need for such features amongts users of pgsql, I see no need in
polluting the codebase with unnecessary complexity.

Let's just not confuse "no need for XYZ functionality" with "XYZ
functionality is lame and can never work in practice".

--
Pip-pip
Sailesh
http://www.cs.berkeley.edu/~sailesh