Re: Incorrect response code after XA recovery

From: Tom Jenkinson <tom(dot)jenkinson(at)redhat(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Ondrej Chaloupka <ochaloup(at)redhat(dot)com>, pgsql-general(at)postgresql(dot)org, pgsql-bugs(at)postgresql(dot)org, Pavel Raiskup <praiskup(at)redhat(dot)com>
Subject: Re: Incorrect response code after XA recovery
Date: 2013-07-29 14:19:34
Message-ID: 51F679F6.4080504@redhat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-general pgsql-jdbc

Hi Tom,

A little bit of information in the linked bugzilla report is that the
exception being returned has an XA error code of XAER_RMERR "An error
occurred in rolling back the transaction branch. The resource manager is
free to forget about the branch when returning this error so long as all
accessing threads of control have been notified of the branch’s state."

That does not sound right to me, wouldn't XAER_NOTA "The specified XID
is not known by the resource manager" be more accurate?

Thanks,
Tom

On 29/07/13 14:50, Tom Lane wrote:
> Ondrej Chaloupka <ochaloup(at)redhat(dot)com> writes:
>> The OTS specification requires both bottom up and top down recovery to be triggered by the recovering resource. This causes that two rollback calls are done against the DB. DB receives rollback call and does the rollback. Then for the second time it returns the exceptional code. As the DB already rollbacked the transaction and forgot about it the DB returns error that no such transaction exists. But this seems to be against OTS specification.
> It's not likely that we would consider changing the behavior of ROLLBACK
> PREPARED. The alternatives we would have are (1) silently accept a
> ROLLBACK against a non-existent transaction ID, or (2) remember every
> rolled-back ID forever. Neither seems sane in the least.
>
> It seems to me that this is something client-side code, probably the XA
> manager, would need to deal with. The XA manager already has to track
> uncommitted 2-phase transactions, and would furthermore have the best
> idea of when it would be safe to forget about a rolled-back ID.
>
> Right offhand it appears to me that that Red Hat bug is filed against
> the correct component, and you need to push them harder to fix their
> bug/shortcoming rather than claim it's our problem.
>
> regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2013-07-29 14:46:12 Re: Incorrect response code after XA recovery
Previous Message Euclid Nikiforov 2013-07-29 13:55:13 Re: BUG #8334: Merge Join drops records

Browse pgsql-general by date

  From Date Subject
Next Message Ingmar Brouns 2013-07-29 14:27:45 Re: to_char with locale decimal separator
Previous Message Javier de la Torre 2013-07-29 14:08:01 Re: Event trigger information accessibility on plpgsql

Browse pgsql-jdbc by date

  From Date Subject
Next Message Tom Lane 2013-07-29 14:46:12 Re: Incorrect response code after XA recovery
Previous Message Tom Lane 2013-07-29 13:50:24 Re: [BUGS] Incorrect response code after XA recovery