Re: Two weeks to feature freeze

Tom Lane wrote:

> The Hermit Hacker <scrappy@postgresql.org> 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
mascarm@mascari.com