Tom Lane wrote: > The Hermit Hacker <[EMAIL PROTECTED]> writes: > >>Hrmmm, I see Tom's point (I think!) ... but what if, for instance, the >>co-ordinator crashes? > > Or you just lose the network connection for awhile. The worst case > scenario I think is where the co-ordinator got everyone's promise to > commit, and told some of the subordinates to commit, but your own > response gets lost due to network failure. Now what? If you time > out and decide to abort, you're inconsistent with the other > subordinates. On the other hand, you can't commit after a timeout > either, because that loses in the other scenario (where the coordinator > didn't decide to commit). Basically, the subordinate must be willing > to hold its breath *forever*.
Yep. And if the cohort crashes while waiting for the coordinator to come back on-line, if I understand the world correctly, it must be capable of committing the database changes associated with the COMMIT-VOTE response it supplied to the coordinator's PREPARE. It seems this would require REDO? And yet there are thousands of installed distributed databases running enterprises every day. A paper on a "A New Presumed Commit Optimization for Two Phase Commit" describes the cohort as: "If a prepared cohort does not receive a transaction outcome message promptly, or crashes without remembering the outcome, the cohort asks the coordinator for the outcome. It keeps on asking until it gets an answer. (This is the blocking aspect of 2PC.)" I'd just like to point out that: 1) The XA interface defines a 2PC protocol library which allows transaction managers, such as BEAS Tuxedo (and Oracle, for that matter) to use the database in a distributed transaction. Lack of an XA interface for PostgreSQL prohibits its use in major enterprise applications. BEAS Tuxedo can talk to PostgreSQL, but won't allow it to participate in a distributed tx. 2) The users of distributed databases will/should/can know that a cohort will block waiting for the coordinator. We're not talking asynchronous multi-master replication of 4 databases distributed over low-speed communication lines across the country. We're talking about the sales dept. database having a few linked tables to the accounting dept. database, where inserts into the one result in inserts into the other. Mike Mascari [EMAIL PROTECTED] ---------------------------(end of broadcast)--------------------------- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])