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

From Oliver Jowett
Subject Re: 2PC transaction id
Date
Msg-id 42C4B61C.20808@opencloud.com
Whole thread Raw
In response to Re: 2PC transaction id  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: 2PC transaction id
List pgsql-hackers
Tom Lane wrote:
> Oliver Jowett <oliver@opencloud.com> writes:
> 
>>Ok, so how do we get XA working when a single global transaction
>>involves two databases on the same cluster?
> 
> 
> It's the TM's responsibility to deal with that.  I would expect it to
> hand out transaction IDs that consist of a common prefix and a
> per-database suffix, if it does not know which resources it's dealing
> with might share a common GID namespace.

Hm, that's not how I read the spec :(  Throughout the API is the
implication that you can have more than one RM associated with a
transaction branch.

For example, 3.3.1 says:

> 3.3.1 Registration of Resource Managers
> Normally, a TM involves all associated RMs in a transaction branch. (The TM’s set of
> RM switches, described in Section 4.3 on page 21 tells the TM which RMs are
> associated with it.) The TM calls all these RMs with xa_start(), xa_end(), and
> xa_prepare (), although an RM that is not active in a branch need not participate further
> (see Section 2.3.2 on page 8). A technique to reduce overhead for infrequently-used
> RMs is discussed below.

I don't know if we can reasonably expect TMs not to hand out an
identical XID to different RMs in the same global transaction.

(anyone with experience with how existing TMs behave want to chime in?)

-O


pgsql-hackers by date:

Previous
From: Christopher Kings-Lynne
Date:
Subject: TODO item done
Next
From: "Marc G. Fournier"
Date:
Subject: Re: [ANNOUNCE] Language to use with SQL database - Number ONE computer