Re: 2PC transaction id

Поиск
Список
Период
Сортировка
От Oliver Jowett
Тема Re: 2PC transaction id
Дата
Msg-id 42C4AE26.6060702@opencloud.com
обсуждение исходный текст
Ответ на Re: 2PC transaction id  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: 2PC transaction id  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: 2PC transaction id  (Heikki Linnakangas <hlinnaka@iki.fi>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: 2PC transaction id
Следующее
От: Tom Lane
Дата:
Сообщение: Re: 2PC transaction id