On Fri, Sep 29, 2017 at 4:22 AM, Craig Ringer <cr...@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
