On Wed, Mar 22, 2017 at 2:08 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On 22 March 2017 at 17:41, Robert Haas <robertmhaas@gmail.com> wrote:
>> + if (TransactionIdIsCurrentTransactionId(xid))
>> + status = gettext_noop("in progress");
>> + else if (TransactionIdDidCommit(xid))
>> + status = gettext_noop("committed");
>> + else if (TransactionIdDidAbort(xid))
>> + status = gettext_noop("aborted");
>> + else
>> +
>> + /*
>> + * can't test TransactionIdIsInProgress here or we race with
>> + * concurrent commit/abort. There's no point anyway, since it
>> + * might then commit/abort just after we check.
>> + */
>> + status = gettext_noop("in progress");
>>
>> I am not sure this is going to do the right thing for transactions
>> that are aborted by a crash without managing to write an abort record.
>
> Yes, perhaps we should report that state as "aborted - incomplete".
>
> And of course, we might return "subcommitted" also, which could
> technically also be an abort in some cases, so we'd need to do a wait
> loop on that.
I actually don't think those are things we should expose to users.
They're internal implementation details. The user had better not care
whether an abort was the type of abort that wrote an abort record or
the type that didn't.
> Which makes me think it would be confusing to say "in progress" for
> when it is our current xid, since the user might wait until it is
> complete and then wait forever. Prefer it if it said "in progress -
> current transaction"
Hmm, or just "current transaction", maybe?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company