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

On Mon, Nov 9, 2015 at 4:33 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On 8 November 2015 at 16:59, Konstantin Knizhnik <k.knizhnik@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