Re: Do we need to handle orphaned prepared transactions in the server?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Craig Ringer <craig(at)2ndquadrant(dot)com>
Cc: Ants Aasma <ants(at)cybertec(dot)at>, Hamid Akhtar <hamid(dot)akhtar(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Do we need to handle orphaned prepared transactions in the server?
Date: 2020-01-22 15:05:39
Message-ID: 6434.1579705539@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Craig Ringer <craig(at)2ndquadrant(dot)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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Kellerer 2020-01-22 15:16:19 Re: Do we need to handle orphaned prepared transactions in the server?
Previous Message Tomas Vondra 2020-01-22 14:26:18 Re: We're getting close to the end of 2020-01 CF