Re: pg_prepared_xact_status

On 29 September 2017 at 15:57, Konstantin Knizhnik <
k(dot)knizhnik(at)postgrespro(dot)ru> wrote:

> So you are saying that Postgresql 2PC mechanism is not complete and user
> needs to maintain some extra information to make it work?
>

No, it provides what's needed for an implementation of what in XA terms is
a local resource manager (LRM). What it does not provide is infrastructure
to make postgres its self into a global transaction manager (GTM) for
co-ordinating multiple LRMs.

It sounds like you're trying to build a GTM using PostgreSQL's existing LRM
book-keeping as your authorative data store, right?

> The problems with 2PC arrive when coordinator node is not available but is
> expected to be recovered in future.
> In this case we may have not enough information to make a decision whether
> to abort or commit prepared transaction.
> But it is a different story. We need to use 3PC or some other protocol to
> prevent such situation.

In that case the node sits and waits patiently for the GTM (or in more
complex architectures, *a* valid voting quorum of GTMs) to be reachable
again. Likely using a protocol like Raft, Paxos, 3PC etc to co-ordinate.

It can't do anything else, since if it unilaterally commits or rolls back
it might later find out that the nodes on the other side of the network
partition or whatever made the opposite decision and, boom!

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services