Re: 2PC transaction id - Mailing list pgsql-hackers

From Oliver Jowett
Subject Re: 2PC transaction id
Date
Msg-id 42C4AE26.6060702@opencloud.com
Whole thread Raw
In response to Re: 2PC transaction id  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: 2PC transaction id
Re: 2PC transaction id
List pgsql-hackers
Tom Lane wrote:
> Oliver Jowett <oliver@opencloud.com> writes:
> 
>>Can we make the GID-to-internal-xid mapping for prepared transactions
>>1:N rather than the current 1:1?
> 
> 
> No.

Ok, so how do we get XA working when a single global transaction
involves two databases on the same cluster?

The scenario is:

- there are two independent resource managers participating in a single
global transaction
- each resource manager has a connection to the database it is managing,
and a SQL-level transaction running against that database
- the global TM tells both resource managers to prepare their part of
the global transaction, passing the same XID to both
- the resource manager translates the xa_prepare() call to a PREPARE
TRANSACTION query, using the passed XID as the GID.

Currently, one of the PREPARE TRANSACTIONs is going to fail if the two
databases happen to be running under the same postmaster.

For this particular case we could embed the database name in the GID,
but unfortunately that doesn't work in the more general case where you
could have two RMs (perhaps in different processes) talking to the same
database.

Perhaps the second and subsequent RM to prepare could detect the
duplicate GID and add a sequence number or something similar to the end
-- and reverse this process on commit/rollback/recovery -- but I don't
see how you'd do this atomically with the PREPARE TRANSACTION.

-O


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: 2PC transaction id
Next
From: Tom Lane
Date:
Subject: Re: 2PC transaction id