Skip site navigation (1) Skip section navigation (2)

Re: 2PC transaction id

From: Oliver Jowett <oliver(at)opencloud(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Dave Cramer <pg(at)fastcrypt(dot)com>,PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>,Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Subject: Re: 2PC transaction id
Date: 2005-07-01 02:44:54
Message-ID: 42C4AE26.6060702@opencloud.com (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
Tom Lane wrote:
> Oliver Jowett <oliver(at)opencloud(dot)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

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2005-07-01 02:51:44
Subject: Re: 2PC transaction id
Previous:From: Tom LaneDate: 2005-07-01 02:26:35
Subject: Re: 2PC transaction id

pgsql-patches by date

Next:From: Tom LaneDate: 2005-07-01 02:51:44
Subject: Re: 2PC transaction id
Previous:From: Tom LaneDate: 2005-07-01 02:26:35
Subject: Re: 2PC transaction id

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group