Re: eXtensible Transaction Manager API - Mailing list pgsql-hackers

On 11/08/2015 02:46 PM, Michael Paquier wrote:

On Sun, Nov 8, 2015 at 1:53 AM, Konstantin Knizhnik wrote:

In tsDTM approach two phase commit is performed by coordinator and currently
is using standard PostgreSQL two phase commit:

Code in GO performing two phase commit:

           exec(conn1, "prepare transaction '" + gtid + "'")
           exec(conn2, "prepare transaction '" + gtid + "'")
           exec(conn1, "select dtm_begin_prepare($1)", gtid)
           exec(conn2, "select dtm_begin_prepare($1)", gtid)
           csn = _execQuery(conn1, "select dtm_prepare($1, 0)", gtid)
           csn = _execQuery(conn2, "select dtm_prepare($1, $2)", gtid, csn)
           exec(conn1, "select dtm_end_prepare($1, $2)", gtid, csn)
           exec(conn2, "select dtm_end_prepare($1, $2)", gtid, csn)
           exec(conn1, "commit prepared '" + gtid + "'")
           exec(conn2, "commit prepared '" + gtid + "'")

If commit at some of the nodes failed, coordinator should rollback prepared
transaction at all nodes.

Not always. If COMMIT PREPARED fails at some of the nodes but succeeds
on others, the transaction is already partially acknowledged as
committed in the cluster. Hence it makes more sense for the
coordinator to commit transactions on the remaining nodes. Before
issuing any COMMIT PREPARED queries, I guess that's fine to rollback
the transactions on all nodes though.

We will get inconsistency if  transaction is committed on some subset of nodes involved in transaction.
Assume bank debit-credit example. If some distributed transaction transfers money from the account at one node to the account and another node,
then committing transaction just at one node cause incorrect total balance.
The main goal of DTM is to preserve ACID semantic for distributed transaction, so either transaction is committed at all nodes, either it is not committed at all.