On 05.08.2013 17:58, Jeremy Whiting wrote:
Hello Tom,
A quick update on progress. A second PR was created to provide a patch.
https://github.com/pgjdbc/pgjdbc/pull/76
Thanks. Looks good to me.
I wish the backend would throw a more specific error code for this,
42704 is used for many other er
Hello Tom,
A quick update on progress. A second PR was created to provide a patch.
https://github.com/pgjdbc/pgjdbc/pull/76
Regards,
Jeremy
On 31/07/13 12:36, Jeremy Whiting wrote:
Hi Tom,
The driver currently doesn't report back to the calling client (tm)
XAException.XAER_NOTA code as Ondr
Hi Tom,
The driver currently doesn't report back to the calling client (tm)
XAException.XAER_NOTA code as Ondrej and Tom Jenkinson have identified.
Instead it returns XAException.XAER_RMERR. See line 416
https://github.com/pgjdbc/pgjdbc/blob/master/org/postgresql/xa/PGXAConnection.java#416
whic
Tom Jenkinson escribió:
> Hi Alban,
>
> I stripped down the code to a raw XA example using the latest
> postgres driver available in maven central. It demonstrates that
> regardless of what the codebase might suggest, it is certainly the
> case that postgres is returning XAER_RMERR in the scenario
Hi Alban,
I stripped down the code to a raw XA example using the latest postgres
driver available in maven central. It demonstrates that regardless of
what the codebase might suggest, it is certainly the case that postgres
is returning XAER_RMERR in the scenario where the resource manager no
On Jul 29, 2013, at 16:57, Tom Jenkinson wrote:
> Hi Tom,
>
> On Mon 29 Jul 2013 15:46:12 BST, Tom Lane wrote:
>> Tom Jenkinson writes:
>>> 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
>>> occurre
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
Hi Tom,
On Mon 29 Jul 2013 15:46:12 BST, Tom Lane wrote:
Tom Jenkinson writes:
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
fr
Tom Jenkinson writes:
> 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
Tom Jenkinson writes:
> On Mon 29 Jul 2013 15:46:12 BST, Tom Lane wrote:
>> No idea, but in any case that's outside Postgres' purview. It's barely
>> possible that the Postgres JDBC driver has something to do with that,
>> but it sounds more like the XA manager's turf.
> I am not sure what you m
Ondrej Chaloupka 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
Hi,
I would like to consult with you a problematic response put by PostgreSQL after
transaction recovery run by Narayana (JBossTS).
I work on tests for Narayana and I hit a issue with PostgreSQL. The db returns
incorrect code XAException.XA_HEURHAZ when the TM does recovery after crash of
the
12 matches
Mail list logo
