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
Re: 2PC transaction id |
Список | 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 по дате отправления: