Do the transaction id's used in 2PC need to be unique across all
sessions?

Do we provide a mechanism for this ?

If not shouldn't we provide a way to create a unique transaction id ?


Dave Cramer
davec@postgresintl.com
www.postgresintl.com
ICQ #14675561
jabber davecramer@jabber.org
ph (519 939 0336 )


---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

On Thu, Jun 30, 2005 at 06:39:43PM -0400, Dave Cramer wrote:
> Do the transaction id's used in 2PC need to be unique across all
> sessions?

Yes.

> Do we provide a mechanism for this ?

Huh, the constraint is enforced by the server, but the ID is generated
by the client.

> If not shouldn't we provide a way to create a unique transaction id ?

Maybe a new function would suffice.

--
Alvaro Herrera (<alvherre[a]surnet.cl>)
"Use it up, wear it out, make it do, or do without"

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

In reality all it takes is a sequence, however if it were system
generated it would be simpler

Dave
On 30-Jun-05, at 6:46 PM, Alvaro Herrera wrote:

> On Thu, Jun 30, 2005 at 06:39:43PM -0400, Dave Cramer wrote:
>
>> Do the transaction id's used in 2PC need to be unique across all
>> sessions?
>>
>
> Yes.
>
>
>> Do we provide a mechanism for this ?
>>
>
> Huh, the constraint is enforced by the server, but the ID is generated
> by the client.
>
>
>> If not shouldn't we provide a way to create a unique transaction id ?
>>
>
> Maybe a new function would suffice.
>
> --
> Alvaro Herrera (<alvherre[a]surnet.cl>)
> "Use it up, wear it out, make it do, or do without"
>
>


---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Dave Cramer wrote:
> Do the transaction id's used in 2PC need to be unique across all sessions?

They are global IDs, yes.

> Do we provide a mechanism for this ?
>
> If not shouldn't we provide a way to create a unique transaction id ?

Well, in XA the XIDs are assigned by the TM, the individual resources
(e.g. a postgresql backend) just get *given* an XID to use.

-O

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

I'm thinking of the situation where one transaction occurs on more
than one backend, and there is
more than one transaction manager.

Dave
On 30-Jun-05, at 7:37 PM, Oliver Jowett wrote:

> Dave Cramer wrote:
>
>> Do the transaction id's used in 2PC need to be unique across all
>> sessions?
>>
>
> They are global IDs, yes.
>
>
>> Do we provide a mechanism for this ?
>>
>> If not shouldn't we provide a way to create a unique transaction id ?
>>
>
> Well, in XA the XIDs are assigned by the TM, the individual resources
> (e.g. a postgresql backend) just get *given* an XID to use.
>
> -O
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to
> majordomo@postgresql.org
>
>


---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org

Dave Cramer wrote:
> I'm thinking of the situation where one transaction occurs on more than
> one backend, and there is
> more than one transaction manager.

XA XIDs are *global* IDs, i.e. they are unique even with more than one
TM involved. It's the responsibility of the TM to generate a
globally-unique XID.

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)

It's even possible for one resource to do two different independent
(local) transactions that are part of the same global transaction -- in
that case, the local transactions will be given different XIDs though.

But all of this allocation / management of XIDs is done by the TM, the
individual resources don't need to do anything beyond associating
particular transactions with client-supplied XIDs, which we already do
AFAIK.

-O

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

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.

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

On 30-Jun-05, at 8:00 PM, Oliver Jowett wrote:

> Dave Cramer wrote:
>
>> I'm thinking of the situation where one transaction occurs on
>> more than
>> one backend, and there is
>> more than one transaction manager.
>>
>
> XA XIDs are *global* IDs, i.e. they are unique even with more than one
> TM involved. It's the responsibility of the TM to generate a
> globally-unique XID.
>
> 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)
I understand this
>
> It's even possible for one resource to do two different independent
> (local) transactions that are part of the same global transaction
> -- in
> that case, the local transactions will be given different XIDs though.
>
> But all of this allocation / management of XIDs is done by the TM, the
> individual resources don't need to do anything beyond associating
> particular transactions with client-supplied XIDs, which we already do
> AFAIK.
I was actually thinking more of the people without the advantage of
an application server
Also for the case where some lowlevel replicator wanted to use 2PC.
Probably a moot point
as anyone capable of writing one is also capable of getting a unique XID
>
> -O
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
>
>


---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

Dave Cramer <pg@fastcrypt.com> writes:
> Do the transaction id's used in 2PC need to be unique across all
> sessions?
> Do we provide a mechanism for this ?
> If not shouldn't we provide a way to create a unique transaction id ?

I see no value in that at all. The point of 2PC is to synchronize with
other databases running other transactions; an ID assigned by one
database that can only be guaranteed unique with respect to that
database is really pretty useless. In practice the IDs will be assigned
by the transaction manager module according to its own needs.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

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.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq