Re: eXtensible Transaction Manager API

On 8 November 2015 at 23:35, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
wrote:

> > 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 :)
>

This is wrong.

There is no "approach proposed", this is just normal 2PC feature that
PostgreSQL has supported since 8.1. All that is proposed here is that we
have an API that allows this to be exposed.

The whole point of PREPARE is that it allows a database to crash after that
step and it can still be recovered. That has nothing to do with Xanything.

In this case, the role of the GTM is to record the commit. Other nodes
consult the GTM, not local state to see whether the transaction has
committed, acting as the transaction manager in an XA sense.

--
Simon Riggs http://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services