On Tue, 7 Jun 2005, Alvaro Herrera wrote:
On Sat, May 21, 2005 at 06:57:24PM +0300, Heikki Linnakangas wrote:
Heikki,
I took a closer look at the JTA spec and saw that the Xid, which is
translated to a gid in the jdbc driver, consists of a format identifier
(32-bit int), a branch qualifier
On 6/11/05, Heikki Linnakangas wrote:
It matches with the format in the JTA spec, but the JTA spec also mentions
the OCI CCR format
The OSI CCR format, which appears to refer to ISO/IEC 9805-1.
ISO/IEC 9805-1:1998
15-12-1998
Information technology - Open Systems Interconnection - Protocol
On Sat, 11 Jun 2005, Jochem van Dieten wrote:
The OSI CCR format, which appears to refer to ISO/IEC 9805-1.
ISO/IEC 9805-1:1998
15-12-1998
Information technology - Open Systems Interconnection - Protocol for
the Commitment, Concurrency and Recovery service element: Protocol
specification
This
On Saturday 21 May 2005 03:37, Josh Berkus wrote:
2PC is a key to supporting 3rd-party replication tools, like C-JDBC.
I don't think C-JDBC requires 2PC for replication. Mixed up acronyms maybe? :)
--
Jose Orlando Pereira
---(end of
On Friday 20 May 2005 18:14, Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
As I remember, you said two-phase wasn't 100% reliable and we just
needed a way to report failures.
[ Shrug... ] I remain of the opinion that 2PC is a solution in search
of a problem, because it does
On Thu, 19 May 2005, Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
* I'm inclined to think that the gid identifiers for prepared
transactions ought to be SQL identifiers (names), not string literals.
Was there a particular reason for making them strings?
Sure. No Reason.
Tom Lane wrote:
I've started to look seriously at Heikki's patch for two-phase commit.
There are a few issues that probably deserve discussion:
* The major missing issue that I've come across so far is that
subtransaction and multixact state isn't preserved across a crash.
I am a little
Bruce Momjian pgman@candle.pha.pa.us writes:
I am a little confused by this. How does two-phase commit add extra
requirements on crash recovery?
Uh, that's more or less the entire *POINT*. Once an open transaction is
prepared, it's supposed to survive a server crash.
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
I am a little confused by this. How does two-phase commit add extra
requirements on crash recovery?
Uh, that's more or less the entire *POINT*. Once an open transaction is
prepared, it's supposed to survive a server crash.
Bruce Momjian pgman@candle.pha.pa.us writes:
Tom Lane wrote:
Uh, that's more or less the entire *POINT*. Once an open transaction is
prepared, it's supposed to survive a server crash.
Wow. This is much more than I thought we were going to do.
If we tried to claim that anything less was
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Tom Lane wrote:
Uh, that's more or less the entire *POINT*. Once an open transaction is
prepared, it's supposed to survive a server crash.
Wow. This is much more than I thought we were going to do.
If we tried to claim
Bruce Momjian pgman@candle.pha.pa.us writes:
As I remember, you said two-phase wasn't 100% reliable and we just
needed a way to report failures.
[ Shrug... ] I remain of the opinion that 2PC is a solution in search
of a problem, because it does not solve the single point of failure
issue (just
Exactly. A 2PC expects every participant that makes it to the prepare to commit phase to survive a server restart, controller or otherwise. Anything less is not 2PC.
Jordan Henderson
On Fri, 2005-05-20 at 12:07 -0400, Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
I am a
Tom Lane wrote:
[ Shrug... ] I remain of the opinion that 2PC is a solution in search
of a problem, because it does not solve the single point of failure
issue (just moves same from the database to the 2PC controller).
But some people want it anyway, and they aren't going to be satisfied
Tom,
[ Shrug... ] I remain of the opinion that 2PC is a solution in search
of a problem, because it does not solve the single point of failure
issue (just moves same from the database to the 2PC controller).
But some people want it anyway, and they aren't going to be satisfied
that we
On Wed, 18 May 2005, Tom Lane wrote:
* The major missing issue that I've come across so far is that
subtransaction and multixact state isn't preserved across a crash.
Assuming that we want to store only top-level XIDs in the shared-memory
list of prepared XIDs (which I think is important), it is
Heikki Linnakangas [EMAIL PROTECTED] writes:
As Alvaro pointed out elsewhere, the multixacts are harder because a
backend doesn't know which multixactids it belongs to. AFAICS, the most
straightforward solution is to xlog every CreateMultixact call, so that
the multixact slru files can be
I've started to look seriously at Heikki's patch for two-phase commit.
There are a few issues that probably deserve discussion:
* The major missing issue that I've come across so far is that
subtransaction and multixact state isn't preserved across a crash.
Assuming that we want to store only
Hi,
One thing I would suggest is to start a global transaction in begin, not in
prepare. That is way to be compliance with XA.
Thanks
Joe
On 5/18/05 2:15 PM, Tom Lane [EMAIL PROTECTED] wrote:
I've started to look seriously at Heikki's patch for two-phase commit.
There are a few issues that
On Wed, May 18, 2005 at 05:15:09PM -0400, Tom Lane wrote:
I've started to look seriously at Heikki's patch for two-phase commit.
Hum. I started a few days ago doing some reviewing, with the intention
of correcting some things here and there in order to present it all to
you later, with a
Alvaro Herrera [EMAIL PROTECTED] writes:
On Wed, May 18, 2005 at 05:15:09PM -0400, Tom Lane wrote:
Similarly, we've got to reconstruct MultiXactIds that any prepared
xacts are members of, else row-level locks taken out by prepared xacts
won't be enforced correctly. I think this can be handled
On Wed, May 18, 2005 at 07:29:38PM -0400, Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
On Wed, May 18, 2005 at 05:15:09PM -0400, Tom Lane wrote:
Similarly, we've got to reconstruct MultiXactIds that any prepared
xacts are members of, else row-level locks taken out by prepared
Alvaro Herrera [EMAIL PROTECTED] writes:
On Wed, May 18, 2005 at 07:29:38PM -0400, Tom Lane wrote:
What I had in mind was that each prepared xact's state file would just
list the MultiXactIds it belongs to.
Hm, this assumes the transaction knows what MultiXactIds it belongs to.
This is not
23 matches
Mail list logo
