>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 ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
