Tom Lane schrieb am 22.01.2020 um 16:05:
> Craig Ringer <craig@2ndquadrant.com> writes:
>> So I don't really see the point of doing anything with 2PC xacts
>> within Pg proper. It's the job of the app that prepares the 2PC xacts,
>> and if that app is unable to resolve them for some reason there's no
>> generally-correct action to take without administrator action.
>
> Right. It's the XA transaction manager's job not to forget uncommitted
> transactions. Reasoning as though no TM exists is not only not very
> relevant, but it might lead you to put in features that actually
> make the TM's job harder. In particular, a timeout (or any other
> mechanism that leads PG to abort or commit a prepared transaction
> of its own accord) does that.
>
> Or another way to put it: the fundamental premise of a prepared
> transaction is that it will be possible to commit it on-demand with
> extremely low chance of failure. Designing in a reason why we'd
> fail to be able to do that would be an anti-feature.
That's a fair point, but the reality is that not all XA transaction managers
do a good job with that.
Having somthing on the database side that can handle that in
exceptional cases would be very welcome.
(In Oracle you can't sometimes even run DML on tables where you have orphaned
XA transactions - which is extremely annoying, because by default
only the DBA can clean that up)
Thomas