On Sat, 2 Jul 2005, Oliver Jowett wrote:
Sorry to keep beating on this, but I still don't see where the spec says
that you must have only one RM per transaction branch.
Sure, it's important to get this right.
2.2.6 says:
2.2.6 Transaction Branches
A global transaction has one or more
It certainly helps if you need to debug a process.
Ken
On Fri, Jul 01, 2005 at 09:06:03PM +0300, Heikki Linnakangas wrote:
On Fri, 1 Jul 2005, Oliver Jowett wrote:
PS: noticed in passing: psql's help doesn't seem to know about the 2PC
command syntax yet.
True.
Should we add support
On Fri, 1 Jul 2005, Oliver Jowett wrote:
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
On Fri, 1 Jul 2005, Oliver Jowett wrote:
Heikki Linnakangas wrote:
branch id: Branch Identifier. Every RM involved in the global
transaction is given a *different* branch id.
Hm, I am confused then -- the XA spec definitely talks about enlisting
multiple RMs in a single transaction branch.
Heikki Linnakangas wrote:
On Fri, 1 Jul 2005, Oliver Jowett wrote:
Heikki Linnakangas wrote:
branch id: Branch Identifier. Every RM involved in the global
transaction is given a *different* branch id.
Hm, I am confused then -- the XA spec definitely talks about enlisting
multiple RMs in
branch id: Branch Identifier. Every RM involved in the global
transaction is given a *different* branch id.
Hm, I am confused then -- the XA spec definitely talks about
enlisting
multiple RMs in a single transaction branch.
Can you explain?
I oversimplified a bit. The TM *can* enlist
On Fri, 1 Jul 2005, Oliver Jowett wrote:
What I'm confused about is, for example, 3.3.1 in the DTP:XA spec:
3.3.1 Registration of Resource Managers
Normally, a TM involves all associated RMs in a transaction branch. (The TMs
set of
RM switches, described in Section 4.3 on page 21 tells the
Heikki Linnakangas wrote:
On Fri, 1 Jul 2005, Oliver Jowett wrote:
PS: noticed in passing: psql's help doesn't seem to know about the 2PC
command syntax yet.
True.
Should we add support for it? 2PC is not something you normally do
interactively...
Yes, we should add psql support
On Fri, 1 Jul 2005, Oliver Jowett wrote:
PS: noticed in passing: psql's help doesn't seem to know about the 2PC
command syntax yet.
True.
Should we add support for it? 2PC is not something you normally do
interactively...
- Heikki
---(end of
Heikki Linnakangas [EMAIL PROTECTED] writes:
On Fri, 1 Jul 2005, Oliver Jowett wrote:
PS: noticed in passing: psql's help doesn't seem to know about the 2PC
command syntax yet.
True.
Really?
regression=# \h commit prepared
Command: COMMIT PREPARED
Description: commit a transaction that
Tom Lane wrote:
regression=# \h commit prepared
Command: COMMIT PREPARED
Description: commit a transaction that was earlier prepared for two-phase
commit
Syntax:
COMMIT PREPARED transaction_id
Ah, I was looking under '\h commit', '\h prepare' etc.
-O
Heikki Linnakangas wrote:
On Fri, 1 Jul 2005, Oliver Jowett wrote:
That implies it's valid (in fact, normal!) to enlist many different RMs
in the same transaction branch. Am I interpreting that correctly?
I see. No, I don't think that's the correct interpretation, though now
that you
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?
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
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
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
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
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.
Dave Cramer [EMAIL PROTECTED] 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
Oliver Jowett [EMAIL PROTECTED] 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
Tom Lane wrote:
Oliver Jowett [EMAIL PROTECTED] 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:
Oliver Jowett [EMAIL PROTECTED] 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
Tom Lane wrote:
Oliver Jowett [EMAIL PROTECTED] 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
Oliver Jowett wrote:
Tom Lane wrote:
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.
I don't know
24 matches
Mail list logo
