On Mon, Nov 9, 2015 at 4:33 AM, Simon Riggs <si...@2ndquadrant.com> wrote: > On 8 November 2015 at 16:59, Konstantin Knizhnik <k.knizh...@postgrespro.ru> > wrote: >> >> 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. > > > Agreed. > > COMMIT PREPARED is a pretty thin layer; the work is all done in the PREPARE. > With a DTM, the main commit itself is done once only in the DTM, so all the > COMMIT PREPARED would do is release local node resources.
Sure. Now imagine that the pg_twophase entry is corrupted for this transaction on one node. This would trigger a PANIC on it, and transaction would not be committed everywhere. I am aware of the fact that by definition PREPARE TRANSACTION ensures that a transaction will be committed with COMMIT PREPARED, just trying to see any corner cases with the approach proposed. The DTM approach is actually rather close to what a GTM in Postgres-XC does :) -- Michael -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers