Re: pg_prepared_xact_status

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

>
> The idea of pg_prepared_xact_status function is that it allows to get
> status of 2PC transaction without any additional requirements to GIDs and
> any other additional information about participants of 2PC transaction.
>
>
This sounds kind-of like 1/4 of a distributed transaction resolver, without
a way to make it reliable enough to build the other 3/4.

To make this practical I think you'd need a way to retain historic GIDs +
their outcomes, and a way to prune that information only once an
application knows all interested participants consider the transaction
finalized.

I'd be all for a global xid status function if there were a good way to
manage resource retention. But it's fuzzy enough for txid_status, which
isn't really making any firm promises, just improving on the prior state of
"no f'ing idea what happened to that tx, sorry". 2PC consumers will want
absolute guarantees, not "dunno, sorry".

(Ahem, HeuristicMixedException raises its hand. You, sit down! You can only
get that if you mix 2PC and !2PC xacts).

I can see it being useful for Pg to be able to report a stream of GIDs +
outcomes for applications to consume. But unless you have either:

* some kind of app-controlled retention horizon and a way to multiplex it
for >1 app (like slots do); or

* a node registry where Pg its self implements a full built-in transaction
resolver;

then I think it's probably not going to get far.

I could see a full DTC resolver in postgres one day, once we have things
like working in-core logical rep based multi-master with 2PC support. But
that's a looooooong way off.

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