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 >
beleft 'in doubt' about the fate of the transaction. In practice, with > replicated data 'never' recovering is
virtuallyimpossible, but just waiting > for some human to replace failed hardware can stall things enough that a >
morecomplex 'three-phase commit' model exists where nodes need not wait for > the coordinator to recover. Another
mannerin which that issue is addressed > is by having a 'back-up' coordinator to which coordination responsibility >
canbe transferred; a third is by having a robust coordinator - e.g., whose > storage can be 'failed over' to another
separatesystem 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