Re: [HACKERS] Two-phase commit issues

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 Thi

Re: [HACKERS] Two-phase commit issues

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 - Protoc

Re: [HACKERS] Two-phase commit issues

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 (m

Re: [HACKERS] Two-phase commit issues

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 broadcast)--

Re: [HACKERS] Two-phase commit issues

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.

Re: [HACKERS] Two-phase commit issues

On Friday 20 May 2005 18:14, Tom Lane wrote: > Bruce Momjian 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

Re: [HACKERS] Two-phase commit issues

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 > >

Re: [HACKERS] Two-phase commit issues

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 >

Re: [HACKERS] Two-phase commit issues

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 writes: > I am

Re: [HACKERS] Two-phase commit issues

Bruce Momjian 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 moves same from the

Re: [HACKERS] Two-phase commit issues

Tom Lane wrote: > Bruce Momjian 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 anythi

Re: [HACKERS] Two-phase commit issues

Bruce Momjian 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 two-phase commit, we

Re: [HACKERS] Two-phase commit issues

Tom Lane wrote: > Bruce Momjian 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. Wow. This is muc

Re: [HACKERS] Two-phase commit issues

Bruce Momjian 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. regards, tom lane --

Re: [HACKERS] Two-phase commit issues

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

Re: [HACKERS] Two-phase commit issues

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

Re: [HACKERS] Two-phase commit issues

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 es

Re: [HACKERS] Two-phase commit issues

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

Re: [HACKERS] Two-phase commit issues

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 p

Re: [HACKERS] Two-phase commit issues

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

Re: [HACKERS] Two-phase commit issues

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 pre-fi

Re: [HACKERS] Two-phase commit issues

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

[HACKERS] Two-phase commit issues

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 top-