Re: 2PC transaction id

Oliver Jowett wrote:

> If you have two different databases involved in the same global
> transaction, then yes, the two backends could be told to use the same
> global XID. That's normal. (they don't *have* to be given the same XID
> as they could be participating in two independent branches of the same
> global transaction, and in that case the global XIDs will have different
> branch qualifiers)

Thinking about this some more -- it may be necessary for the same XID to
be associated with more than one backend transaction at once, possibly
even in the same database. This could happen if there are two clients
involved in the same global transaction with no branch qualifier change,
or if one client manages to get two separate resources that point at the
same database.

[... experiments ...]

Ok, so the second case is actually even more general, since
pg_prepared_xacts is scoped cluster-wide not database-wide. So any
global transaction that involves two databases on the same cluster could
be affected.

It seems that you can't PREPARE TRANSACTION more than once (per cluster)
with the same GID. That's a bit painful..

Can we make the GID-to-internal-xid mapping for prepared transactions
1:N rather than the current 1:1? COMMIT PREPARED and ROLLBACK PREPARED
would need either syntax or behaviour changes: either we need to
identify a particular transaction (perhaps via the xid from
pg_prepared_xacts.transaction), or they need to operate on *all*
transactions with the given GID.

I have no idea on how nasty it is to implement this though :)

Heikki, any thoughts?

-O

PS: noticed in passing: psql's help doesn't seem to know about the 2PC
command syntax yet.