On Sep 29, 2017, at 11:33 PM, Robert Haas wrote:
> 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.
txid_status() also not always be able to return status of transaction (if wraparound happen).
But it is still considered as one of the key features of 10 (transaction traceability...).
>
> I think the approach this patch takes is a non-starter for exactly the
> reasons you have stated.
Actually I do not propose pg_prepared_xact_status as mechanism for constructing GTM or some other complete 2PC
infrastructure.
It is just simple function, using existed PostgreSQL log iteration utilities, simplifying extraction of information
about2PC transactions.
The same think can be done manually using pg_waldump. But it is very inconvenient.
So I do not see any troubles caused by adding this functions. And it can really be helpful for DBA in some cases.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers