Re: [HACKERS] Two phase commit in ECPG

> Yes. I added two-phase commit test to "make check" test schedule > while > adding new two type of test. Thank you, committed. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael at xmpp dot meskes

Re: [HACKERS] Two phase commit in ECPG

On Fri, Mar 17, 2017 at 5:50 PM, Michael Meskes wrote: >> Thank you for pointing out. >> Yeah, I agree that the twophase regression test should not be >> performed by default as long as the default value of >> max_prepared_transactions is 0. Similar to this, the isolation check >> regression test

Re: [HACKERS] Two phase commit in ECPG

> Thank you for pointing out. > Yeah, I agree that the twophase regression test should not be > performed by default as long as the default value of > max_prepared_transactions is 0. Similar to this, the isolation check > regression test does same thing. Attached patch removes sql/twophase > from s

Re: [HACKERS] Two phase commit in ECPG

On Fri, Mar 17, 2017 at 4:34 PM, Masahiko Sawada wrote: > On Fri, Mar 17, 2017 at 12:17 PM, Kuntal Ghosh > wrote: >> On Tue, Mar 14, 2017 at 1:35 AM, Michael Meskes >> wrote: Previous 002 patch lacked to add describing PREPARE TRANSACTION. Attached updated 002 patch. >>> >>> I just co

Re: [HACKERS] Two phase commit in ECPG

On Fri, Mar 17, 2017 at 12:17 PM, Kuntal Ghosh wrote: > On Tue, Mar 14, 2017 at 1:35 AM, Michael Meskes wrote: >>> Previous 002 patch lacked to add describing PREPARE TRANSACTION. >>> Attached updated 002 patch. >> >> I just committed both patches and a backport of the bug fix itself. >> Thanks a

Re: [HACKERS] Two phase commit in ECPG

On Tue, Mar 14, 2017 at 1:35 AM, Michael Meskes wrote: >> Previous 002 patch lacked to add describing PREPARE TRANSACTION. >> Attached updated 002 patch. > > I just committed both patches and a backport of the bug fix itself. > Thanks again for finding and fixing. Regression tests for sql/twophase

Re: [HACKERS] Two phase commit in ECPG

> Previous 002 patch lacked to add describing PREPARE TRANSACTION. > Attached updated 002 patch. I just committed both patches and a backport of the bug fix itself. Thanks again for finding and fixing. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)

Re: [HACKERS] Two phase commit in ECPG

On Sat, Mar 4, 2017 at 4:11 AM, Michael Meskes wrote: > Dear Sawada-san, > >> This cause is that the "begin transaction" is issued automatically >> before executing COMMIT PREPARED if we're not in auto commit. The >> Commit 816b008eaf1a1ff1069f3bafff363a9a8bf04a21 fixed bug of >> incorrect >> stat

Re: [HACKERS] Two phase commit in ECPG

Dear Sawada-san, > This cause is that the "begin transaction" is issued automatically > before executing COMMIT PREPARED if we're not in auto commit. The > Commit 816b008eaf1a1ff1069f3bafff363a9a8bf04a21 fixed bug of > incorrect > status calculation but at the same time it became the cause of this

[HACKERS] Two phase commit in ECPG

Hi all, I found that ecpg has not been supporting COMMIT PREPARED and ROLLBACK PREPARED since version 9.0.2. For example, if the test code does, EXEC SQL BEGIN; EXEC SQL INSERT INTO t1 VALUES(1); EXEC SQL PREPARE TRANSACTION 'gxid'; EXEC SQL COMMIT PREPARED 'gxid'; I got error "COMMIT PREP

Re: [HACKERS] Two-phase commit

Tom Lane wrote: > While cleaning out old mail about two-phase commit, I noticed this > thought from Oliver: > > Oliver Jowett <[EMAIL PROTECTED]> writes: > >>> Probably the next question is, do we want a database-side timeout on > >>> how long prepared txns can stay alive before being summarily r

Re: [HACKERS] Two-phase commit

While cleaning out old mail about two-phase commit, I noticed this thought from Oliver: Oliver Jowett <[EMAIL PROTECTED]> writes: >>> Probably the next question is, do we want a database-side timeout on >>> how long prepared txns can stay alive before being summarily rolled back? >> >> That soun

Re: [HACKERS] Two-phase commit

Bruce Momjian writes: > Where are we on 2-phase commit? Alvaro posted a patch. Is he > completing it for 8.1? Is Tom? Hacking on it now ... regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list arc

[HACKERS] Two-phase commit

Where are we on 2-phase commit? Alvaro posted a patch. Is he completing it for 8.1? Is Tom? -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be

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

I have added this thread as a link on the TODO list under TODO.detail. I know folks are working on this for 8.1 but now they can get the discussions all in one place. --- Heikki Linnakangas wrote: > I've been very slowly co

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-

Re: [HACKERS] Two phase commit

On Tue, 5 Apr 2005, Alvaro Herrera wrote: What happenned to your two phase commit patch? Are you still working on it? Have you got something done from the last time we heard from you? I've kept it up-to-date by doing "cvs update" every now and then and fixing possible conflicts. It would be nic

Re: [HACKERS] Two-phase commit for 8.1

On Sun, Jan 23, 2005 at 07:32:55PM +0200, Heikki Linnakangas wrote: > If it helps, I could try to split it into two patches, one with code > rearrangements that don't change current behaviour, and then the actual > 2PC stuff on top of that. I think that'd be a good idea, because such a patch co

Re: [HACKERS] Two-phase commit for 8.1

On Sun, 23 Jan 2005, Alvaro Herrera wrote: On Sun, Jan 23, 2005 at 01:37:30PM +0200, Heikki Linnakangas wrote: As the patch gets more attention, I'm sure more issues will come up. I see the changes to the lock manager are huge. Can you explain what's the idea behind those? Do you release the loc

Re: [HACKERS] Two-phase commit for 8.1

On Sun, Jan 23, 2005 at 01:37:30PM +0200, Heikki Linnakangas wrote: > As the patch gets more attention, I'm sure more issues will come up. I see the changes to the lock manager are huge. Can you explain what's the idea behind those? Do you release the locks and then reacquire them, or do you re

Re: [HACKERS] Two-phase commit for 8.1

On Sun, 23 Jan 2005, Hans-Jürgen Schönig wrote: Heikki, What is still missing to complete the 2PC patch?. Here's my TODO on things that need to be done: * large objects * guc variables * notify/listen Large objects and notify/listen should be quite straightforward. GUC variables need s

Re: [HACKERS] Two-phase commit for 8.1

Heikki, What is still missing to complete the 2PC patch?. Regards, Hans Heikki Linnakangas wrote: On Wed, 19 Jan 2005, Tom Lane wrote: "Marc G. Fournier" <[EMAIL PROTECTED]> writes: If the patch is ready to be committed early in the cycle, I'd say most definitely ... just de

Re: [HACKERS] Two-phase commit for 8.1

On Wed, 19 Jan 2005, Tom Lane wrote: "Marc G. Fournier" <[EMAIL PROTECTED]> writes: If the patch is ready to be committed early in the cycle, I'd say most definitely ... just depends on how late in the cycle its ready ... My recollection is that it's quite far from being complete. I had hoped to s

Re: [HACKERS] Two-phase commit for 8.1

On Wed, Jan 19, 2005 at 07:42:03PM -0500, Tom Lane wrote: > "Marc G. Fournier" <[EMAIL PROTECTED]> writes: > > If the patch is ready to be committed early in the cycle, I'd say most > > definitely ... just depends on how late in the cycle its ready ... > > My recollection is that it's quite far f

Re: [HACKERS] Two-phase commit for 8.1

On Thursday 20 January 2005 04:16, Christopher Kings-Lynne wrote: > > If the patch is ready to be committed early in the cycle, I'd say most > > definitely ... just depends on how late in the cycle its ready ... > > > > I *believe* that 8.1, we're looking at a 2mo cycle before beta, so > > figure b

Re: [HACKERS] Two-phase commit for 8.1

If the patch is ready to be committed early in the cycle, I'd say most definitely ... just depends on how late in the cycle its ready ... I *believe* that 8.1, we're looking at a 2mo cycle before beta, so figure beta for ~April 1st (no april fools jokes, eh?) ... You guys are crazy :) We haven'

Re: [HACKERS] Two-phase commit for 8.1

"Marc G. Fournier" <[EMAIL PROTECTED]> writes: > If the patch is ready to be committed early in the cycle, I'd say most > definitely ... just depends on how late in the cycle its ready ... My recollection is that it's quite far from being complete. I had hoped to spend some time during the 8.1 c

Re: [HACKERS] Two-phase commit for 8.1

If the patch is ready to be committed early in the cycle, I'd say most definitely ... just depends on how late in the cycle its ready ... I *believe* that 8.1, we're looking at a 2mo cycle before beta, so figure beta for ~April 1st (no april fools jokes, eh?) ... On Wed, 19 Jan 2005, Heikki Lin

[HACKERS] Two-phase commit for 8.1

Hi, Now that we got 8.0 out of the door, I'm submitting my two-phase commit patch again for discussion. http://www.hut.fi/~hlinnaka/pgsql/ Do we want it in 8.1, if we want a short development cycle? It needs a new pg_twophase subdirectory, and it introduces a new system view, so I guess it requ

Re: [HACKERS] Two-phase commit security restrictions

David Garamond wrote: So it is possible for a user connected to the DB to send random commit or cancel commands, just in case she happens to hit a valid GID? It is not essentially different from someone trying to bruteforce a password. A 128bit value like a random GUID is as strong as a 16 char

Re: [HACKERS] Two-phase commit security restrictions

Alvaro Herrera wrote: Another approach I've been thinking about is to allow anyone that knows the (user-supplied) global transaction identifier to finish the transaction, and hide the gids of running transactions from regular users. That way, the gid acts as a secret token that's only known by t

Re: [HACKERS] Two-phase commit security restrictions

Heikki, > Another approach I've been thinking about is to allow anyone that knows > the (user-supplied) global transaction identifier to finish the > transaction, and hide the gids of running transactions from regular users. > That way, the gid acts as a secret token that's only known by the > tra

Re: [HACKERS] Two-phase commit security restrictions

Heikki Linnakangas wrote: Another approach I've been thinking about is to allow anyone that knows the (user-supplied) global transaction identifier to finish the transaction, and hide the gids of running transactions from regular users. That way, the gid acts as a secret token that's only known

Re: [HACKERS] Two-phase commit security restrictions

On Wed, 13 Oct 2004, Peter Eisentraut wrote: Heikki Linnakangas wrote: What kind of security restrictions do we want for prepared transactions? Who has the right to finish a transaction that was started by user A? At least the original user, I suppose, but who else? Do we not require transaction in

Re: [HACKERS] Two-phase commit security restrictions

Heikki Linnakangas wrote: > What kind of security restrictions do we want for prepared > transactions? Who has the right to finish a transaction that was > started by user A? At least the original user, I suppose, but who > else? Do we not require transaction initiation and conclusion to happen in

Re: [HACKERS] Two-phase commit security restrictions

On Wed, Oct 13, 2004 at 11:58:21PM +0700, David Garamond wrote: > Heikki Linnakangas wrote: > >Another approach I've been thinking about is to allow anyone that knows > >the (user-supplied) global transaction identifier to finish the > >transaction, and hide the gids of running transactions from

Re: [HACKERS] Two-phase commit security restrictions

Heikki Linnakangas wrote: What kind of security restrictions do we want for prepared transactions? Who has the right to finish a transaction that was started by user A? At least the original user, I suppose, but who else? Under what account is the transaction manager typically going to run? A s

Re: [HACKERS] Two-phase commit security restrictions

Heikki Linnakangas <[EMAIL PROTECTED]> writes: > What kind of security restrictions do we want for prepared transactions? > Who has the right to finish a transaction that was started by user A? At > least the original user, I suppose, but who else? I would say the original user, any superuser, a

[HACKERS] Two-phase commit security restrictions

What kind of security restrictions do we want for prepared transactions? Who has the right to finish a transaction that was started by user A? At least the original user, I suppose, but who else? Under what account is the transaction manager typically going to run? A separate TM account perhaps

Re: [HACKERS] Two-phase commit

On Wed, 6 Oct 2004, Tom Lane wrote: Quite some time ago, Heikki Linnakangas <[EMAIL PROTECTED]> wrote: I haven't received any comments and there hasn't been any discussion on the implementation, I suppose that nobody has given it a try. :( I finally got around to taking a close look at this. There

[HACKERS] Two-phase commit patch updated

I brought the 2PC patch up to date: http://www.hut.fi/~hlinnaka/pgsql/ There's no new functionality, I just fixed all the bit rot so that it applies to the current CVS tip. - Heikki ---(end of broadcast)--- TIP 2: you can get off all lists at once w

Re: [HACKERS] Two-phase commit

On Thu, 7 Oct 2004, Oliver Jowett wrote: Probably the next question is, do we want a database-side timeout on how long prepared txns can stay alive before being summarily rolled back? That sounds very dangerous to me. You could end up breaking global atomicity if some other resource in the global

Re: [HACKERS] Two-phase commit

On Thu, 7 Oct 2004, Zeugswetter Andreas DAZ SD wrote: Note that this is only really necessary because of Heikki's choice to make the API work in terms of a user-assigned GID. This was not an arbitrary choice, but is required by most/all TX managers :-( I agree that it would be cleaner for the tx ma

Re: [HACKERS] Two-phase commit

Heikki Linnakangas wrote: On Thu, 7 Oct 2004, Oliver Jowett wrote: Probably the next question is, do we want a database-side timeout on how long prepared txns can stay alive before being summarily rolled back? That sounds very dangerous to me. You could end up breaking global atomicity if some o

Re: [HACKERS] Two-phase commit

Fabien COELHO <[EMAIL PROTECTED]> writes: > Sorry for this stupid general comment, but why couldn't the gid be stored > in some shared system table that would rely on pg infrastructure for > caching, sharing, locking and so on? That would have a number of pitfalls of its own: * No outside-a-tra

Re: [HACKERS] Two-phase commit

> Well, the question is how long must the individual databases retain > state with which to answer "recover" requests. I don't like "forever", > so I'm proposing that there should be an explicit command to say "you > can forget about this gid". I think it would be ok to forget the gid after:

Re: [HACKERS] Two-phase commit

Implementation-wise, I really dislike storing the info in a shared hash table, because I don't see any reasonable bound on the size of the hash table (your existing code uses 100 which is about as arbitrary as it gets). [...] The idea that occurs to me instead is to not use WAL or shared memory at

Re: [HACKERS] Two-phase commit

Rod Taylor wrote: On Wed, 2004-10-06 at 18:50, Tom Lane wrote: Well, the question is how long must the individual databases retain state with which to answer "recover" requests. I don't like "forever", so I'm proposing that there should be an explicit command to say "you can forget about this gid"

Re: [HACKERS] Two-phase commit

Alvaro Herrera <[EMAIL PROTECTED]> writes: > I am concerned with a different issue: what issues arise regarding > snapshots? Do concurrent xacts see a prepared one as running? I'm not > sure but I think so. So they have to be able to at least get its Xid, > no? Hmm, that's a good point. It see

Re: [HACKERS] Two-phase commit

Tom Lane wrote: Oliver Jowett <[EMAIL PROTECTED]> writes: Tom Lane wrote: Well, the question is how long must the individual databases retain state with which to answer "recover" requests. As I understand it, you don't need to keep state for committed txns, I think that's clearly wrong: T

Re: [HACKERS] Two-phase commit

On Wed, Oct 06, 2004 at 05:46:10PM -0400, Tom Lane wrote: > You were concerned about how to mark prepared transactions in pg_clog, > given that Alvaro had already commandeered state '11' for > subtransactions. Since only a toplevel transaction can be prepared, > it might work to allow state '11'

Re: [HACKERS] Two-phase commit

Oliver Jowett <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> Well, the question is how long must the individual databases retain >> state with which to answer "recover" requests. > As I understand it, you don't need to keep state for committed txns, I think that's clearly wrong: TM --

Re: [HACKERS] Two-phase commit

On Wed, 2004-10-06 at 18:50, Tom Lane wrote: > Oliver Jowett <[EMAIL PROTECTED]> writes: > >> At the API level, I like the PREPARE/COMMIT/ROLLBACK statements, but I > >> think you have missed a bet in that it needs to be possible to issue > >> "COMMIT PREPARED gid" for the same gid several times wi

Re: [HACKERS] Two-phase commit

Tom Lane wrote: Oliver Jowett <[EMAIL PROTECTED]> writes: At the API level, I like the PREPARE/COMMIT/ROLLBACK statements, but I think you have missed a bet in that it needs to be possible to issue "COMMIT PREPARED gid" for the same gid several times without error. Isn't this usually where the GTM

Re: [HACKERS] Two-phase commit

Oliver Jowett <[EMAIL PROTECTED]> writes: >> At the API level, I like the PREPARE/COMMIT/ROLLBACK statements, but I >> think you have missed a bet in that it needs to be possible to issue >> "COMMIT PREPARED gid" for the same gid several times without error. > Isn't this usually where the GTM woul

Re: [HACKERS] Two-phase commit

Tom Lane wrote: At the API level, I like the PREPARE/COMMIT/ROLLBACK statements, but I think you have missed a bet in that it needs to be possible to issue "COMMIT PREPARED gid" for the same gid several times without error. Consider a scenario where the transaction monitor crashes during the commit

Re: [HACKERS] Two-phase commit

Quite some time ago, Heikki Linnakangas <[EMAIL PROTECTED]> wrote: > I haven't received any comments and there hasn't been any discussion on > the implementation, I suppose that nobody has given it a try. :( I finally got around to taking a close look at this. There's a good bit undone, as you we

Re: [HACKERS] Two-phase commit

On Tue, Mar 23, 2004 at 06:10:35PM +0200, Heikki Linnakangas wrote: > I have again updated my two-phase commit patches. Only minor > modifications. > > I haven't received any comments and there hasn't been any discussion on > the implementation, I suppose that nobody has given it a try. :( I have

Re: [HACKERS] Two-phase commit

Agreed. I would like to 2-phase commit in 7.5. --- Heikki Linnakangas wrote: > I have again updated my two-phase commit patches. Only minor > modifications. > > I haven't received any comments and there hasn't been any dis

Re: [HACKERS] Two-phase commit

I have again updated my two-phase commit patches. Only minor modifications. I haven't received any comments and there hasn't been any discussion on the implementation, I suppose that nobody has given it a try. :( There is still some rough edges, but I think it's good enough as a first cut. I pers

Re: [HACKERS] Two-phase commit

On Sat, 7 Feb 2004, Bruce Momjian wrote: > > Please have a look and comment, the patches can be found here: > > http://www.iki.fi/hlinnaka/pgsql/ > > > > What is the schedule for 7.5? Any chance of getting this in? > > 7.5 is certainly possible. We are months away from beta on 7.5 and I > would l

Re: [HACKERS] Two-phase commit

On Sun, 8 Feb 2004, Jeroen T. Vermeulen wrote: > On Wed, Feb 04, 2004 at 10:22:16PM +0200, Heikki Linnakangas wrote: > > > There is a system view pg_prepared_xacts that gives you all transactions > > that are in prepared state waiting for COMMITPREPARED or ABORTPREPARED. > > Great to hear that you

Re: [HACKERS] Two-phase commit

On Mon, Feb 09, 2004 at 10:09:34PM +0200, Heikki Linnakangas wrote: > > However, if this gets into 7.5, I guess you could just check for the > version of the backend instead with "SELECT version()". Hey, that works? That's very good news, because I was getting a bit worried about all the things

Re: [HACKERS] Two-phase commit

Heikki Linnakangas wrote: > I've been very slowly continuing my work on two-phase commits for a couple > months now, and I now have my original patch updated so that it applies to > the current CVS tip, with some improvements. > > The patch introduces three new commands, PREPCOMMIT, COMMITPREPARED

[HACKERS] Two-phase commit

I've been very slowly continuing my work on two-phase commits for a couple months now, and I now have my original patch updated so that it applies to the current CVS tip, with some improvements. The patch introduces three new commands, PREPCOMMIT, COMMITPREPARED and ABORTPREPARED. To start a 2PC

Re: [HACKERS] Two Phase Commit WAS: Re: Two weeks to feature freeze

Josh Berkus wrote: Anyway, I would vote for a first implemenation for 2PC which addressed the commit-then-crash issue in some expedient-but-not-reliable way, and putting 2PC in /contrib with a "not for production use" warning. Some people will use it in production anyway, and hopefully one or m

Re: [HACKERS] Two Phase Commit WAS: Re: Two weeks to feature freeze

> I don't think it could have been said any better. There are a host of > improvements on the standard 2PC protocol, including 3PC, multi-cast > 2PC, and other variants both synchronous and asynchronous. But if > PostgreSQL is going to work with XA, then it doesn't get to choose the > TM or the pro

Re: [HACKERS] Two Phase Commit WAS: Re: Two weeks to feature freeze

I second the agreement ... a 'reference implementation', of sorts, at least gives someone to build on then starting right from scratch ... On Mon, 23 Jun 2003, Bruce Momjian wrote: > > Agreed. > > --- > > Josh Berkus wrote

Re: [HACKERS] Two Phase Commit WAS: Re: Two weeks to feature freeze

Rod Taylor wrote: -- Start of PGP signed section. > > Perhaps the people on this list who are pushing 2PC could do the ground work? > > > - 2PC is better than a standard transaction when dealing with multiple > servers as it can recover in some circumstances (but not all). > > - 2PC (XA suppor

Re: [HACKERS] Two Phase Commit WAS: Re: Two weeks to feature freeze

Rod Taylor wrote: >>Perhaps the people on this list who are pushing 2PC could do the ground work? > > - 2PC is better than a standard transaction when dealing with multiple > servers as it can recover in some circumstances (but not all). > > - 2PC (XA support as described by the X/Open group)

Re: [HACKERS] Two Phase Commit WAS: Re: Two weeks to feature freeze

> Perhaps the people on this list who are pushing 2PC could do the ground work? - 2PC is better than a standard transaction when dealing with multiple servers as it can recover in some circumstances (but not all). - 2PC (XA support as described by the X/Open group) is the only implementation o

Re: [HACKERS] Two Phase Commit WAS: Re: Two weeks to feature freeze

Tom, "Putting in "dozens of hours" is not the issue here --- the problem is that there isn't any solution in sight, and I'm not eager to go down a path that has an obvious dead end." Well, I doubt we're breaking any new ground with this discussion. If I really cared about this feature, I would

Re: [HACKERS] Two Phase Commit WAS: Re: Two weeks to feature freeze

Josh Berkus <[EMAIL PROTECTED]> writes: >> No. I want to know what the subordinate does when it's promised to >> commit and the co-ordinator never responds. AFAICS the subordinate >> is screwed --- it can't commit, and it can't abort, and it can't expect >> to make progress indefinitely on other

Re: [HACKERS] Two Phase Commit WAS: Re: Two weeks to feature freeze

Agreed. --- Josh Berkus wrote: > Tom, > > > No. I want to know what the subordinate does when it's promised to > > commit and the co-ordinator never responds. AFAICS the subordinate > > is screwed --- it can't commit, and

Re: [HACKERS] Two Phase Commit WAS: Re: Two weeks to feature freeze

Tom, > No. I want to know what the subordinate does when it's promised to > commit and the co-ordinator never responds. AFAICS the subordinate > is screwed --- it can't commit, and it can't abort, and it can't expect > to make progress indefinitely on other work while it's holding locks > for th

Re: [HACKERS] Two-phase commit

hello, I'm not sure what will your lib solve ? For reliable distributed TX, each SQL server have to support two phase commit. It means to have at least PREPARE command which is identical to COMMIT only doesn't really commit (last commit bit is not written but TX is at commit edge and can't complai

Re: [HACKERS] Two-phase commit

i'm developing one. a library for batch transactions, so you can continue processing in the middle of the file(or table) in case an abort happens. it can support multi-databases. i think i can share it to freshmeat. On Tue, 24 Oct 2000 13:52:38 +0200, [EMAIL PROTECTED] wrote: > Hello, > anyon

[HACKERS] Two-phase commit

Hello, anyone thought about implementing two-phase commit to be able to support distributed transactions ? I have no clue how complex it would be, someone knows ? devik

  1   2   >