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

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

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

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

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.

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

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

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

[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

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

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 rolled back?

[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

Re: [HACKERS] Two-phase commit

Bruce Momjian pgman@candle.pha.pa.us 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

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

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

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 This

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

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

Re: [HACKERS] Two-phase commit issues

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

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

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

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.

Re: [HACKERS] Two-phase commit issues

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.

Re: [HACKERS] Two-phase commit issues

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

Re: [HACKERS] Two-phase commit issues

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

Re: [HACKERS] Two-phase commit issues

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

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 pgman@candle.pha.pa.us writes: I am a

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

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

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

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 be

[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

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 that

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

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 handled

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 prepared

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

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 nice

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

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

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

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

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

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

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

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

[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

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

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 cycle

[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

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

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

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? Do we not require transaction initiation and conclusion to happen in

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

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

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

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

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

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

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

[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

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.

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

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

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: 1.

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

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 well

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

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

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

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 without error.

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

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

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

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 seems

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

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

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 haven't

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

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 like ot see

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

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 I

[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

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

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 it

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 work

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 get

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

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) is the

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

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

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

[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

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