On Fri, Sep 29, 2017 at 4:22 AM, Craig Ringer <craig@2ndquadrant.com> wrote:
> 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".
Very well said, and I agree.
I think the approach this patch takes is a non-starter for exactly the
reasons you have stated.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
