headers
Oliver Jowett | 1 Jul 2005 01:37

Re: 2PC transaction id

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 <at> postgresql.org
Permalink | Reply | 18 comments |
headers
Dave Cramer | 1 Jul 2005 01:47
Favicon

Re: 2PC transaction id

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 <at> postgresql.org
(Continue reading)

Permalink | Reply | 17 comments |
headers
Greg Stark | 1 Jul 2005 01:50
Picon
Favicon

Re: [PATCHES] Dbsize backend integration


Bruce Momjian <pgman <at> candle.pha.pa.us> writes:

> I don't think so.  I think trait and property suggests an aspect of the
> object, so saying trait/property size is saying I am talking about an
> aspect of the object, while for a heap, its size is really its size, it
> isn't an aspect of its size.

I haven't been following this discussion but, uh, does the fact that I have
absolutely no clue what pg_trait_size() or pg_property_size() would be
measuring count for anything? My best guess here is that it's for measuring
the space taken up by a column which doesn't make a lot of sense.

I think you need to think about unambiguous words that help the user
understand what the function does; words that the user might guess if they
were looking for a function to do that, whatever that is.

Not words that are sufficiently vague as to include whatever it's actually
doing but offer no clue what that is. There are an infinite number of such
words to pick and no way for the user to figure out what he or she is looking
for.

--

-- 
greg

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings
Permalink | Reply | 0 comments |
headers
Oliver Jowett | 1 Jul 2005 02:00

Re: 2PC transaction id

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?
(Continue reading)

Permalink | Reply | 16 comments |
headers
Oliver Jowett | 1 Jul 2005 02:37

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
(Continue reading)

Permalink | Reply | 14 comments |
headers
Dave Cramer | 1 Jul 2005 02:53
Favicon

Re: 2PC transaction id


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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tom Lane | 1 Jul 2005 04:21
Picon

Re: 2PC transaction id

Dave Cramer <pg <at> 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
Permalink | Reply | 0 comments |
headers
Tom Lane | 1 Jul 2005 04:26
Picon

Re: 2PC transaction id

Oliver Jowett <oliver <at> 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
Permalink | Reply | 5 comments |
headers
Oliver Jowett | 1 Jul 2005 04:44

Re: 2PC transaction id

Tom Lane wrote:
> Oliver Jowett <oliver <at> 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.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Tom Lane | 1 Jul 2005 04:51
Picon

Re: 2PC transaction id

Oliver Jowett <oliver <at> opencloud.com> writes:
> Ok, so how do we get XA working when a single global transaction
> involves two databases on the same cluster?

It's the TM's responsibility to deal with that.  I would expect it to
hand out transaction IDs that consist of a common prefix and a
per-database suffix, if it does not know which resources it's dealing
with might share a common GID namespace.

There's a reason that the XA spec has such a ridiculously large
requirement for the length of a GID name, and it is that this is the
TM's problem not ours.

			regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend
Permalink | Reply | 2 comments |

Gmane