
Curious bit of synchronicity, related discussion going on in comp.arch
on same topic, lurkers like me might appreciate the explanation given in

http://groups.google.com/groups?selm=svudnRBY5twrXG6jXTWJkQ%40metrocast.net


Tue, 24 Jun 2003 16:49:17 +0800 (MYT)
Ronald Khoo <ronald@cpm.com.my>
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



30 Jun 2003 23:33:04 -0700
Sailesh Krishnamurthy <sailesh@cs.berkeley.edu>
Re: 2PC: discussion in comp.arch