rdelaage/postgresql
1
0
Fork 0
mirror of https://git.postgresql.org/git/postgresql.git synced 2024-09-05 15:39:20 +02:00
Code Issues Packages Projects Releases Wiki Activity
1c6f65db84
postgresql/doc/TODO.detail/2phase
Bruce Momjian 21b1d41ef3 Add 2-phase TODO.detail.
2003-10-24 03:21:37 +00:00

1332 lines
58 KiB
Plaintext
Raw Blame History

From pgsql-hackers-owner+M45196@postgresql.org Thu Oct 9 21:02:52 2003
Return-path: <pgsql-hackers-owner+M45196@postgresql.org>
Received: from www.postgresql.com (www.postgresql.com [64.117.225.209] (may be forged))
by candle.pha.pa.us (8.11.6/8.11.6) with ESMTP id h9A12Sd24438
for <pgman@candle.pha.pa.us>; Thu, 9 Oct 2003 21:02:51 -0400 (EDT)
Received: from postgresql.org (svr1.postgresql.org [64.117.224.193])
by www.postgresql.com (Postfix) with ESMTP
id 65DB0CF4A2C; Thu, 9 Oct 2003 22:02:19 -0300 (ADT)
X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org
Received: from localhost (unknown [64.117.224.130])
by svr1.postgresql.org (Postfix) with ESMTP id F01F8D1B50F
for <pgsql-hackers-postgresql.org@localhost.postgresql.org>; Fri, 10 Oct 2003 01:02:07 +0000 (GMT)
Received: from svr1.postgresql.org ([64.117.224.193])
by localhost (neptune.hub.org [64.117.224.130]) (amavisd-new, port 10024)
with ESMTP id 76113-08
for <pgsql-hackers-postgresql.org@localhost.postgresql.org>;
Thu, 9 Oct 2003 22:01:21 -0300 (ADT)
Received: from ganymede.hub.org (u173n10.eastlink.ca [24.224.173.10])
by svr1.postgresql.org (Postfix) with ESMTP id 1C741D1B4EE
for <pgsql-hackers@postgresql.org>; Thu, 9 Oct 2003 22:01:18 -0300 (ADT)
Received: by ganymede.hub.org (Postfix, from userid 1000)
id 585F835332; Thu, 9 Oct 2003 22:00:10 -0300 (ADT)
Received: from localhost (localhost [127.0.0.1])
by ganymede.hub.org (Postfix) with ESMTP
id 4CD8F35320; Thu, 9 Oct 2003 22:00:10 -0300 (ADT)
Date: Thu, 9 Oct 2003 22:00:10 -0300 (ADT)
From: "Marc G. Fournier" <scrappy@postgresql.org>
X-X-Sender: scrappy@ganymede.hub.org
To: Tatsuo Ishii <t-ishii@sra.co.jp>
cc: andrew@libertyrms.info, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] 2-phase commit
In-Reply-To: <20031010.094635.104030040.t-ishii@sra.co.jp>
Message-ID: <20031009215935.S28590@ganymede.hub.org>
References: <20031009160718.GC14394@libertyrms.info> <1065723448.1821.2288.camel@camel>
<20031009204141.GS14394@libertyrms.info> <20031010.094635.104030040.t-ishii@sra.co.jp>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Virus-Scanned: by amavisd-new at postgresql.org
X-Mailing-List: pgsql-hackers
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org
Status: OR
On Fri, 10 Oct 2003, Tatsuo Ishii wrote:
> > Yes. I don't think that 2PC is a solution for robustness in face of
> > network failure. It's too slow, to begin with. Some sort of
> > multi-master system is very desirable for network failures, &c., but
> > I don't think anybody does active/hot standby with 2PC any more; the
> > performance is too bad.
>
> I'm tired of this kind of "2PC is too slow" arguments. I think
> Satoshi, the only guy who made a trial implementation of 2PC for
> PostgreSQL, has already showed that 2PC is not that slow.
Where does Satoshi's implementation sit right now? Will it patch to v7.4?
Can it provide us with a base to work from, or is it complete?
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly
From pgsql-hackers-owner+M45212@postgresql.org Fri Oct 10 00:22:09 2003
Return-path: <pgsql-hackers-owner+M45212@postgresql.org>
Received: from svr4.postgresql.org (svr4.postgresql.org [64.117.224.192])
by candle.pha.pa.us (8.11.6/8.11.6) with ESMTP id h9A4M7d22170
for <pgman@candle.pha.pa.us>; Fri, 10 Oct 2003 00:22:07 -0400 (EDT)
Received: from postgresql.org (svr1.postgresql.org [64.117.224.193])
by svr4.postgresql.org (Postfix) with ESMTP
id 3EE8D1CB47E5; Fri, 10 Oct 2003 04:22:02 +0000 (GMT)
X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org
Received: from localhost (unknown [64.117.224.130])
by svr1.postgresql.org (Postfix) with ESMTP id D3959D1B517
for <pgsql-hackers-postgresql.org@localhost.postgresql.org>; Fri, 10 Oct 2003 04:21:49 +0000 (GMT)
Received: from svr1.postgresql.org ([64.117.224.193])
by localhost (neptune.hub.org [64.117.224.130]) (amavisd-new, port 10024)
with ESMTP id 22978-01
for <pgsql-hackers-postgresql.org@localhost.postgresql.org>;
Fri, 10 Oct 2003 01:21:04 -0300 (ADT)
Received: from news.hub.org (unknown [64.117.224.194])
by svr1.postgresql.org (Postfix) with ESMTP id D9041D1B52E
for <pgsql-hackers@postgresql.org>; Fri, 10 Oct 2003 01:21:03 -0300 (ADT)
Received: from news.hub.org (host-64-117-224-194.altec1.com [64.117.224.194] (may be forged))
by news.hub.org (8.12.9/8.12.9) with ESMTP id h9A4L3Qh008720
for <pgsql-hackers@postgresql.org>; Fri, 10 Oct 2003 04:21:03 GMT
(envelope-from news@news.hub.org)
Received: (from news@localhost)
by news.hub.org (8.12.9/8.12.9/Submit) id h9A4CJ7w007607
for pgsql-hackers@postgresql.org; Fri, 10 Oct 2003 04:12:19 GMT
X-Newsgroups: comp.databases.postgresql.hackers
Subject: Re: [HACKERS] 2-phase commit
References: <20031009160718.GC14394@libertyrms.info> <1065723448.1821.2288.camel@camel> <20031009204141.GS14394@libertyrms.info> <20031010.094635.104030040.t-ishii@sra.co.jp>
From: Christopher Browne <cbbrowne@acm.org>
X-message-flag: Outlook is rather hackable, isn't it?
X-Home-Page: http://www.cbbrowne.com/info/
X-Affero: http://svcs.affero.net/rm.php?r=cbbrowne
Message-ID: <m31xtl4uk5.fsf@wolfe.cbbrowne.com>
User-Agent: Gnus/5.1003 (Gnus v5.10.3) XEmacs/21.4 (Reasonable Discussion, linux)
Cancel-Lock: sha1:Bu9MHyjwMgreAAWr2UkPGXHzz04=
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Lines: 40
Date: Thu, 09 Oct 2003 23:53:46 -0400
X-Complaints-To: abuse@sympatico.ca
Organization: Bell Sympatico
To: pgsql-hackers@postgresql.org
X-Virus-Scanned: by amavisd-new at postgresql.org
X-Mailing-List: pgsql-hackers
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org
Status: OR
The world rejoiced as t-ishii@sra.co.jp (Tatsuo Ishii) wrote:
> I'm tired of this kind of "2PC is too slow" arguments. I think
> Satoshi, the only guy who made a trial implementation of 2PC for
> PostgreSQL, has already showed that 2PC is not that slow.
I'm tired of it for a different reason, namely that there are "use
cases" where speed is not _relevant_. The REAL problem that is taking
place is that people are talking past each other.
- Some say, "It's too slow; no point in doing it."
The fact that it may be too slow _for them_ means they probably
shouldn't use it. I somehow doubt that there are Vastly Faster
alternatives waiting in the wings.
- The other problem that gets pointed out: "2PC is inherently
fragile, and prone to deadlock."
Again, those that _need_ to use 2PC will forcibly need to address
those concerns in the way they manage their systems.
Those that can't afford the fragility are not 'customers' for use of
2PC. And, pointing back to the speed controversy, it is not at all
obvious that there is any other alternative for handling distributed
processing that _totally addresses_ the concerns about fragility.
Those that can't afford these costs associated with 2PC will simply
Not Use It.
Probably in much the same way that most people _aren't_ using
replication. And most people _aren't_ using PL/R. And most people
_aren't_ using any number of the contributed things.
If 2PC gets implemented, that simply means that there will be another
module that some will be interested in, and which many people won't
bother using. Which shouldn't seem to be a particularly big deal.
--
"aa454","@","freenet.carleton.ca"
http://www.ntlug.org/~cbbrowne/
The way to a man's heart is with a broadsword.
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
From pgsql-hackers-owner+M45350@postgresql.org Tue Oct 14 12:34:46 2003
Return-path: <pgsql-hackers-owner+M45350@postgresql.org>
Received: from svr5.postgresql.org (182.204.46.200.psinetpa.net [200.46.204.182] (may be forged))
by candle.pha.pa.us (8.11.6/8.11.6) with ESMTP id h9EGYid02191
for <pgman@candle.pha.pa.us>; Tue, 14 Oct 2003 12:34:45 -0400 (EDT)
Received: from postgresql.org (svr1.postgresql.org [200.46.204.71])
by svr5.postgresql.org (Postfix) with ESMTP
id 3DE8872EE24; Tue, 14 Oct 2003 16:33:48 +0000 (GMT)
X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org
Received: from localhost (unknown [64.117.224.130])
by svr1.postgresql.org (Postfix) with ESMTP id 4C2BAD1B541
for <pgsql-hackers-postgresql.org@localhost.postgresql.org>; Fri, 10 Oct 2003 05:33:39 +0000 (GMT)
Received: from svr1.postgresql.org ([64.117.224.193])
by localhost (neptune.hub.org [64.117.224.130]) (amavisd-new, port 10024)
with ESMTP id 26706-05
for <pgsql-hackers-postgresql.org@localhost.postgresql.org>;
Fri, 10 Oct 2003 02:32:51 -0300 (ADT)
Received: from mx-00.sil.at (mx-00.sil.at [62.116.68.196])
by svr1.postgresql.org (Postfix) with ESMTP id 274E4D1B517
for <pgsql-hackers@postgresql.org>; Fri, 10 Oct 2003 02:32:49 -0300 (ADT)
Received: (qmail-ldap/ctrl 40676 invoked from network); 10 Oct 2003 05:32:48 -0000
Received: from unknown (HELO waste.silverserver.co.at) ([194.152.178.7]) (envelope-sender <hs@cybertec.at>)
by mx-00.sil.at (qmail-ldap-1.03) with SMTP
for <pgsql-hackers@postgresql.org>; 10 Oct 2003 05:32:48 -0000
Received: from cybertec.at (vie-213-129-225-105.async.sil.at [213.129.225.105])
by waste.silverserver.co.at (8.12.10/8.12.10) with ESMTP id h9A5WhNj032622;
Fri, 10 Oct 2003 07:32:44 +0200
Message-ID: <3F86460B.6030905@cybertec.at>
Date: Fri, 10 Oct 2003 07:39:23 +0200
From: =?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= <hs@cybertec.at>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Marc G. Fournier" <scrappy@postgresql.org>
cc: Tatsuo Ishii <t-ishii@sra.co.jp>, andrew@libertyrms.info,
pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] 2-phase commit
References: <20031009160718.GC14394@libertyrms.info> <1065723448.1821.2288.camel@camel> <20031009204141.GS14394@libertyrms.info> <20031010.094635.104030040.t-ishii@sra.co.jp> <20031009215935.S28590@ganymede.hub.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at postgresql.org
X-Mailing-List: pgsql-hackers
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org
Status: OR
>>I'm tired of this kind of "2PC is too slow" arguments. I think
>>Satoshi, the only guy who made a trial implementation of 2PC for
>>PostgreSQL, has already showed that 2PC is not that slow.
>
>
> Where does Satoshi's implementation sit right now? Will it patch to v7.4?
> Can it provide us with a base to work from, or is it complete?
It is not ready yet.
You can find it at ...
http://snaga.org/pgsql/
It is based on 7.3
* the 2-phase commit protocol (precommit and commit)
* the multi-master replication using 2PC
* distributed transaction (distributed query)
current work
* restarting (from 2nd phase) when the session is disconnected in
2nd phase (XLOG stuffs)
* XA compliance
future work
* hot failover and recovery in PostgreSQL cluster
* data partitioning on different servers
I have compiled it a while ago.
Seems to be pretty nice :).
Hans
--
Cybertec Geschwinde u Schoenig
Ludo-Hartmannplatz 1/14, A-1160 Vienna, Austria
Tel: +43/2952/30706 or +43/660/816 40 77
www.cybertec.at, www.postgresql.at, kernel.cybertec.at
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
From pgsql-hackers-owner+M45361@postgresql.org Tue Oct 14 12:36:29 2003
Return-path: <pgsql-hackers-owner+M45361@postgresql.org>
Received: from svr5.postgresql.org (182.204.46.200.psinetpa.net [200.46.204.182] (may be forged))
by candle.pha.pa.us (8.11.6/8.11.6) with ESMTP id h9EGaOd02587
for <pgman@candle.pha.pa.us>; Tue, 14 Oct 2003 12:36:27 -0400 (EDT)
Received: from postgresql.org (svr1.postgresql.org [200.46.204.71])
by svr5.postgresql.org (Postfix) with ESMTP
id DE0D872EF5B; Tue, 14 Oct 2003 16:35:20 +0000 (GMT)
X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org
Received: from localhost (unknown [64.117.224.130])
by svr1.postgresql.org (Postfix) with ESMTP id 1E506D1B528
for <pgsql-hackers-postgresql.org@localhost.postgresql.org>; Fri, 10 Oct 2003 05:41:53 +0000 (GMT)
Received: from svr1.postgresql.org ([64.117.224.193])
by localhost (neptune.hub.org [64.117.224.130]) (amavisd-new, port 10024)
with ESMTP id 33519-04
for <pgsql-hackers-postgresql.org@localhost.postgresql.org>;
Fri, 10 Oct 2003 02:41:05 -0300 (ADT)
Received: from mx-00.sil.at (mx-00.sil.at [62.116.68.196])
by svr1.postgresql.org (Postfix) with ESMTP id 15845D1B541
for <pgsql-hackers@postgresql.org>; Fri, 10 Oct 2003 02:41:00 -0300 (ADT)
Received: (qmail-ldap/ctrl 41629 invoked from network); 10 Oct 2003 05:40:59 -0000
Received: from unknown (HELO waste.silverserver.co.at) ([194.152.178.7]) (envelope-sender <hs@cybertec.at>)
by mx-00.sil.at (qmail-ldap-1.03) with SMTP
for <pgsql-hackers@postgresql.org>; 10 Oct 2003 05:40:59 -0000
Received: from cybertec.at (vie-213-129-225-110.async.sil.at [213.129.225.110])
by waste.silverserver.co.at (8.12.10/8.12.10) with ESMTP id h9A5etNj000228;
Fri, 10 Oct 2003 07:40:56 +0200
Message-ID: <3F8647F7.7000509@cybertec.at>
Date: Fri, 10 Oct 2003 07:47:35 +0200
From: =?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= <hs@cybertec.at>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020826
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Peter Eisentraut <peter_e@gmx.net>,
Andrew Sullivan <andrew@libertyrms.info>, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] 2-phase commit
References: <200310091442.h99Eg3R29404@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at postgresql.org
X-Mailing-List: pgsql-hackers
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org
Status: OR
>>Why would you spent time on implementing a mechanism whose ultimate
>>benefit is supposed to be increasing reliability and performance, when you
>>already realize that it will have to lock up at the slightest sight of
>>trouble? There are better mechanisms out there that you can use instead.
>
>
> If you want cross-server transactions, what other methods are there that
> are more reliable? It seems network unreliability is going to be a
> problem no matter what method you use.
>
I guess we need something like PITR to make this work because otherwise
I cannot see a way to get in sync again.
Maybe I should call the desired mechanism "Entire cluster back to
transaction X recovery".
Did anybody hear about PITR recently?
How else would you recover from any kind of problem?
No matter what you are doing network reliability will be a problem so we
have to live with it.
Having some "going back to something consistent" is necessary anyway.
People might argue now that committed transactions might be lost. If
people knew which ones, its ok. 90% of all people will understand that
in case of a crash something evil might happen.
Hans
--
Cybertec Geschwinde u Schoenig
Ludo-Hartmannplatz 1/14, A-1160 Vienna, Austria
Tel: +43/2952/30706 or +43/660/816 40 77
www.cybertec.at, www.postgresql.at, kernel.cybertec.at
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
From pgsql-hackers-owner+M45354@postgresql.org Tue Oct 14 12:35:50 2003
Return-path: <pgsql-hackers-owner+M45354@postgresql.org>
Received: from svr4.postgresql.org (70.204.46.200.psinetpa.net [200.46.204.70] (may be forged))
by candle.pha.pa.us (8.11.6/8.11.6) with ESMTP id h9EGZmd02374
for <pgman@candle.pha.pa.us>; Tue, 14 Oct 2003 12:35:49 -0400 (EDT)
Received: from postgresql.org (svr1.postgresql.org [200.46.204.71])
by svr4.postgresql.org (Postfix) with ESMTP
id A59181CB4CC8; Tue, 14 Oct 2003 16:35:03 +0000 (GMT)
X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org
Received: from localhost (unknown [64.117.224.130])
by svr1.postgresql.org (Postfix) with ESMTP id 3AFC7D1B4E2
for <pgsql-hackers-postgresql.org@localhost.postgresql.org>; Sun, 12 Oct 2003 15:41:02 +0000 (GMT)
Received: from svr1.postgresql.org ([64.117.224.193])
by localhost (neptune.hub.org [64.117.224.130]) (amavisd-new, port 10024)
with ESMTP id 87949-06
for <pgsql-hackers-postgresql.org@localhost.postgresql.org>;
Sun, 12 Oct 2003 12:40:28 -0300 (ADT)
Received: from main.gmane.org (main.gmane.org [80.91.224.249])
by svr1.postgresql.org (Postfix) with ESMTP id C8021D1B4EF
for <pgsql-hackers@postgresql.org>; Sun, 12 Oct 2003 12:40:11 -0300 (ADT)
Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian))
id 1A8iKO-0003GE-00
for <pgsql-hackers@postgresql.org>; Sun, 12 Oct 2003 17:40:16 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: pgsql-hackers@postgresql.org
Received: from sea.gmane.org ([80.91.224.252])
by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
id 1A7sHs-0001ff-00
for <gmane-comp-db-postgresql-devel-general@m.gmane.org>; Fri, 10 Oct 2003 10:06:12 +0200
Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian))
id 1A7sHs-0006Wa-00
for <gmane-comp-db-postgresql-devel-general@m.gmane.org>; Fri, 10 Oct 2003 10:06:12 +0200
From: Heikki Linnakangas <hlinnaka@iki.fi>
Subject: Re: [HACKERS] 2-phase commit
Date: Fri, 10 Oct 2003 11:06:11 +0300
Lines: 13
Message-ID: <Pine.OSF.4.58.0310101101400.188711@kosh.hut.fi>
References: <20031010.094635.104030040.t-ishii@sra.co.jp>
<200310100053.h9A0rkl23681@candle.pha.pa.us>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Complaints-To: usenet@sea.gmane.org
X-X-Sender: hlinnaka@kosh.hut.fi
In-Reply-To: <200310100053.h9A0rkl23681@candle.pha.pa.us>
X-Virus-Scanned: by amavisd-new at postgresql.org
X-Mailing-List: pgsql-hackers
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org
Status: OR
On Thu, 9 Oct 2003, Bruce Momjian wrote:
> Agreed. Let's get it into 7.5 and see it in action. If we need to
> adjust it, we can, but right now, we need something for distributed
> transactions, and this seems like the logical direction.
I've started working on two-phase commits last week, and the very
basic stuff is now working. Still a lot of bugs though.
I posted the stuff I've put together to patches-list. I'd appreciate any
comments.
- Heikki
---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend
From pgsql-hackers-owner+M45235@postgresql.org Fri Oct 10 15:27:57 2003
Return-path: <pgsql-hackers-owner+M45235@postgresql.org>
Received: from svr4.postgresql.org (svr4.postgresql.org [64.117.224.192])
by candle.pha.pa.us (8.11.6/8.11.6) with ESMTP id h9AJRud06174
for <pgman@candle.pha.pa.us>; Fri, 10 Oct 2003 15:27:57 -0400 (EDT)
Received: from postgresql.org (svr1.postgresql.org [64.117.224.193])
by svr4.postgresql.org (Postfix) with ESMTP
id E57971CB4834; Fri, 10 Oct 2003 19:27:46 +0000 (GMT)
X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org
Received: from localhost (unknown [64.117.224.130])
by svr1.postgresql.org (Postfix) with ESMTP id E3E14D1B502
for <pgsql-hackers-postgresql.org@localhost.postgresql.org>; Fri, 10 Oct 2003 19:27:28 +0000 (GMT)
Received: from svr1.postgresql.org ([64.117.224.193])
by localhost (neptune.hub.org [64.117.224.130]) (amavisd-new, port 10024)
with ESMTP id 91104-06
for <pgsql-hackers-postgresql.org@localhost.postgresql.org>;
Fri, 10 Oct 2003 16:26:40 -0300 (ADT)
Received: from ns1.oak.forus.or.jp (ns1.oak.forus.or.jp [210.190.22.53])
by svr1.postgresql.org (Postfix) with ESMTP id D3222D1B528
for <pgsql-hackers@postgresql.org>; Fri, 10 Oct 2003 16:26:36 -0300 (ADT)
Received: from athena (W173177.ppp.dion.ne.jp [210.198.173.177])
by ns1.oak.forus.or.jp (8.12.8p1/8.11.3) with SMTP id h9B4dDdV008901;
Sat, 11 Oct 2003 13:39:14 +0900
Date: Sat, 11 Oct 2003 04:26:26 +0900
From: Satoshi Nagayasu <pgsql@snaga.org>
To: Andrew Sullivan <andrew@libertyrms.info>
cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] 2-phase commit
Message-ID: <20031011042626.6019bff2.pgsql@snaga.org>
In-Reply-To: <20031010190255.GT16336@libertyrms.info>
References: <20031009160718.GC14394@libertyrms.info>
<1065723448.1821.2288.camel@camel>
<20031009204141.GS14394@libertyrms.info>
<20031010.094635.104030040.t-ishii@sra.co.jp>
<20031010190255.GT16336@libertyrms.info>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at postgresql.org
X-Mailing-List: pgsql-hackers
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org
Status: OR
Andrew Sullivan <andrew@libertyrms.info> wrote:
> On Fri, Oct 10, 2003 at 09:46:35AM +0900, Tatsuo Ishii wrote:
> > Satoshi, the only guy who made a trial implementation of 2PC for
> > PostgreSQL, has already showed that 2PC is not that slow.
>
> If someone has a fast implementation, so much the better. I'm not
> opposed to fast implementations!
The pgbench results of my experimental 2PC implementation
and plain postgresql are available.
PostgreSQL 7.3
http://snaga.org/pgsql/pgbench/pgbench-REL7_3.log
Experimental 2PC in PostgreSQL 7.3
http://snaga.org/pgsql/pgbench/pgbench-TPC0_0_2.log
I can't see a grave overhead from this comparison.
>
> A
>
> --
> ----
> Andrew Sullivan 204-4141 Yonge Street
> Afilias Canada Toronto, Ontario Canada
> <andrew@libertyrms.info> M2P 2A8
> +1 416 646 3304 x110
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 8: explain analyze is your friend
>
--
NAGAYASU Satoshi <snaga@snaga.org>
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
From pgsql-hackers-owner+M45240@postgresql.org Fri Oct 10 18:29:40 2003
Return-path: <pgsql-hackers-owner+M45240@postgresql.org>
Received: from svr4.postgresql.org (svr4.postgresql.org [64.117.224.192])
by candle.pha.pa.us (8.11.6/8.11.6) with ESMTP id h9AMTdd18233
for <pgman@candle.pha.pa.us>; Fri, 10 Oct 2003 18:29:40 -0400 (EDT)
Received: from postgresql.org (svr1.postgresql.org [64.117.224.193])
by svr4.postgresql.org (Postfix) with ESMTP
id 504471CB4652; Fri, 10 Oct 2003 22:29:32 +0000 (GMT)
X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org
Received: from localhost (unknown [64.117.224.130])
by svr1.postgresql.org (Postfix) with ESMTP id 4DADED1B53E
for <pgsql-hackers-postgresql.org@localhost.postgresql.org>; Fri, 10 Oct 2003 22:29:13 +0000 (GMT)
Received: from svr1.postgresql.org ([64.117.224.193])
by localhost (neptune.hub.org [64.117.224.130]) (amavisd-new, port 10024)
with ESMTP id 15392-08
for <pgsql-hackers-postgresql.org@localhost.postgresql.org>;
Fri, 10 Oct 2003 19:28:29 -0300 (ADT)
Received: from voyager.corporate.connx.com (voyager.corporate.connx.com [65.212.159.131])
by svr1.postgresql.org (Postfix) with ESMTP id A857CD1B4E9
for <pgsql-hackers@postgresql.org>; Fri, 10 Oct 2003 19:28:25 -0300 (ADT)
Content-Class: urn:content-classes:message
Subject: Re: [HACKERS] 2-phase commit
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Date: Fri, 10 Oct 2003 15:28:05 -0700
Message-ID: <D90A5A6C612A39408103E6ECDD77B829408BF2@voyager.corporate.connx.com>
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Thread-Topic: [HACKERS] 2-phase commit
Thread-Index: AcOPezZr87PXbIlLRH6225JV2yf6zgAAc1Ig
From: "Dann Corbit" <DCorbit@connx.com>
To: "Satoshi Nagayasu" <pgsql@snaga.org>,
"Andrew Sullivan" <andrew@libertyrms.info>
cc: <pgsql-hackers@postgresql.org>
X-Virus-Scanned: by amavisd-new at postgresql.org
X-Mailing-List: pgsql-hackers
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by candle.pha.pa.us id h9AMTdd18233
Status: OR
> -----Original Message-----
> From: Satoshi Nagayasu [mailto:pgsql@snaga.org]
> Sent: Friday, October 10, 2003 12:26 PM
> To: Andrew Sullivan
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] 2-phase commit
>
> Andrew Sullivan <andrew@libertyrms.info> wrote:
> > On Fri, Oct 10, 2003 at 09:46:35AM +0900, Tatsuo Ishii wrote:
> > > Satoshi, the only guy who made a trial implementation of 2PC for
> > > PostgreSQL, has already showed that 2PC is not that slow.
> >
> > If someone has a fast implementation, so much the better. I'm not
> > opposed to fast implementations!
>
> The pgbench results of my experimental 2PC implementation
> and plain postgresql are available.
>
> PostgreSQL 7.3
> http://snaga.org/pgsql/pgbench/pgbench-REL7_3.log
>
> Experimental 2PC in PostgreSQL 7.3
> http://snaga.org/pgsql/pgbench/pgbench-TPC0_0_2.log
>
> I can't see a grave overhead from this comparison.
2PC is absolutely essential when you have to have both parts of the
transaction complete for a logical unit of work. For a project that
needs it, if you don't have it you will be forced to go to another tool,
or perform lots of custom programming to work around it.
If you have 2PC and it is ten times slower than without it, you will
still need it for projects requiring that capability.
Now, a good model to start with is a very good idea. So some discussion
and analysis is a good thing. From the looks of it, Satoshi Nagayasu
has done a very good job. Having a functional 2PC would be a huge
feather in the cap of PostgreSQL.
IMO-YMMV
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
From pgsql-hackers-owner+M45242@postgresql.org Fri Oct 10 23:22:31 2003
Return-path: <pgsql-hackers-owner+M45242@postgresql.org>
Received: from svr5.postgresql.org (svr5.postgresql.org [64.117.225.181])
by candle.pha.pa.us (8.11.6/8.11.6) with ESMTP id h9B3MUd13414
for <pgman@candle.pha.pa.us>; Fri, 10 Oct 2003 23:22:30 -0400 (EDT)
Received: from postgresql.org (svr1.postgresql.org [64.117.224.193])
by svr5.postgresql.org (Postfix) with ESMTP
id 9C48072DCAF; Sat, 11 Oct 2003 03:22:23 +0000 (GMT)
X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org
Received: from localhost (unknown [64.117.224.130])
by svr1.postgresql.org (Postfix) with ESMTP id 547CED1B55D
for <pgsql-hackers-postgresql.org@localhost.postgresql.org>; Sat, 11 Oct 2003 03:21:58 +0000 (GMT)
Received: from svr1.postgresql.org ([64.117.224.193])
by localhost (neptune.hub.org [64.117.224.130]) (amavisd-new, port 10024)
with ESMTP id 74332-03
for <pgsql-hackers-postgresql.org@localhost.postgresql.org>;
Sat, 11 Oct 2003 00:21:15 -0300 (ADT)
Received: from news.hub.org (unknown [64.117.224.194])
by svr1.postgresql.org (Postfix) with ESMTP id EB54CD1B51D
for <pgsql-hackers@postgresql.org>; Sat, 11 Oct 2003 00:21:10 -0300 (ADT)
Received: from news.hub.org (host-64-117-224-194.altec1.com [64.117.224.194] (may be forged))
by news.hub.org (8.12.9/8.12.9) with ESMTP id h9B3LAQh017763
for <pgsql-hackers@postgresql.org>; Sat, 11 Oct 2003 03:21:10 GMT
(envelope-from news@news.hub.org)
Received: (from news@localhost)
by news.hub.org (8.12.9/8.12.9/Submit) id h9B3JDdq017363
for pgsql-hackers@postgresql.org; Sat, 11 Oct 2003 03:19:13 GMT
X-Newsgroups: comp.databases.postgresql.hackers
Subject: Re: [HACKERS] 2-phase commit
References: <D90A5A6C612A39408103E6ECDD77B829408BF2@voyager.corporate.connx.com>
From: Christopher Browne <cbbrowne@acm.org>
X-message-flag: Outlook is rather hackable, isn't it?
X-Home-Page: http://www.cbbrowne.com/info/
X-Affero: http://svcs.affero.net/rm.php?r=cbbrowne
Message-ID: <m3u16gzdp4.fsf@wolfe.cbbrowne.com>
User-Agent: Gnus/5.1003 (Gnus v5.10.3) XEmacs/21.4 (Reasonable Discussion, linux)
Cancel-Lock: sha1:YeipjZkXVBbpujQ/QjmB13rksFQ=
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Lines: 52
Date: Fri, 10 Oct 2003 22:54:31 -0400
X-Complaints-To: abuse@sympatico.ca
Organization: Bell Sympatico
To: pgsql-hackers@postgresql.org
X-Virus-Scanned: by amavisd-new at postgresql.org
X-Mailing-List: pgsql-hackers
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org
Status: OR
Martha Stewart called it a Good Thing whenDCorbit@connx.com ("Dann Corbit")wrote:
>> I can't see a grave overhead from this comparison.
>
> 2PC is absolutely essential when you have to have both parts of the
> transaction complete for a logical unit of work. For a project that
> needs it, if you don't have it you will be forced to go to another
> tool, or perform lots of custom programming to work around it.
>
> If you have 2PC and it is ten times slower than without it, you will
> still need it for projects requiring that capability.
Just so.
I would be completely unsurprised if an attempt to use 2PC to support
generalized "multimaster replication" would involve 10-fold slowdowns
as compared to having all the activity take place on one database.
Which would imply that 2PC is not a tool that may be appropriately
used to naively do replication. But that should not come as any grand
surprise.
To each tool the right job, and to each job the right tool...
There seems to be enough room for there to be evidence both of 2PC
being useful for improving performance, and for it to cut
performance:
- TPC benchmarks often specify the inclusion of Tuxedo as a
component; the combination of vendors would surely NOT put it
on the list if it were not an aid to performance;
- There is also indication that there can be a cost, notably in the
form of the concerns of deadlock, but it should also be obvious
that slow network links would lead to _hideous_ increases in
latency.
As you say, even if there is a substantial cost, it's still worthwhile
if a project needs it.
> Now, a good model to start with is a very good idea. So some
> discussion and analysis is a good thing. From the looks of it,
> Satoshi Nagayasu has done a very good job. Having a functional 2PC
> would be a huge feather in the cap of PostgreSQL.
It would seem so. I look forward to seeing how this progresses.
--
wm(X,Y):-write(X),write('@'),write(Y). wm('cbbrowne','acm.org').
http://cbbrowne.com/info/linuxdistributions.html
"XFS might (or might not) come out before the year 3000. As far as
kernel patches go, SGI are brilliant. As far as graphics, especially
OpenGL, go, SGI is untouchable. As far as filing systems go, a
concussed doormouse in a tarpit would move faster." -- jd on Slashdot
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings
From pgsql-hackers-owner+M45243@postgresql.org Sat Oct 11 00:39:02 2003
Return-path: <pgsql-hackers-owner+M45243@postgresql.org>
Received: from svr5.postgresql.org (svr5.postgresql.org [64.117.225.181])
by candle.pha.pa.us (8.11.6/8.11.6) with ESMTP id h9B4d0d19644
for <pgman@candle.pha.pa.us>; Sat, 11 Oct 2003 00:39:01 -0400 (EDT)
Received: from postgresql.org (svr1.postgresql.org [64.117.224.193])
by svr5.postgresql.org (Postfix) with ESMTP
id 141E272E6B5; Sat, 11 Oct 2003 04:38:54 +0000 (GMT)
X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org
Received: from localhost (unknown [64.117.224.130])
by svr1.postgresql.org (Postfix) with ESMTP id 90A3AD1B4E3
for <pgsql-hackers-postgresql.org@localhost.postgresql.org>; Sat, 11 Oct 2003 04:38:35 +0000 (GMT)
Received: from svr1.postgresql.org ([64.117.224.193])
by localhost (neptune.hub.org [64.117.224.130]) (amavisd-new, port 10024)
with ESMTP id 76273-09
for <pgsql-hackers-postgresql.org@localhost.postgresql.org>;
Sat, 11 Oct 2003 01:37:54 -0300 (ADT)
Received: from voyager.corporate.connx.com (voyager.corporate.connx.com [65.212.159.131])
by svr1.postgresql.org (Postfix) with ESMTP id 0C599D1B4FE
for <pgsql-hackers@postgresql.org>; Sat, 11 Oct 2003 01:37:49 -0300 (ADT)
Content-Class: urn:content-classes:message
Subject: Re: [HACKERS] 2-phase commit
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Date: Fri, 10 Oct 2003 21:37:53 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Message-ID: <D90A5A6C612A39408103E6ECDD77B8294CE1EC@voyager.corporate.connx.com>
Thread-Topic: [HACKERS] 2-phase commit
Thread-Index: AcOPp2jLw1yNPbdnRFGP5HwssCpXCwACbcFw
From: "Dann Corbit" <DCorbit@connx.com>
To: "Christopher Browne" <cbbrowne@acm.org>, <pgsql-hackers@postgresql.org>
X-Virus-Scanned: by amavisd-new at postgresql.org
X-Mailing-List: pgsql-hackers
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by candle.pha.pa.us id h9B4d0d19644
Status: OR
Why not apply the effort to something already done and compatibly
licensed?
This:
http://dog.intalio.com/ots.html
Appears to be a Berkeley style licensed:
http://dog.intalio.com/license.html
Transaction monitor.
"Overview
The OpenORB Transaction Service is a very scalable transaction monitor
which also provides several extensions like XA management, a management
interface to control all transaction processes and a high reliable
recovery system.
By coordinating OpenORB and OpenORB Transaction Service, you provide a
reliable and powerful foundation for building large scalable distributed
applications.
Datasheet
The OpenORB Transaction Service is a fully compliant implementation of
the OMG Transaction Service specification.
The OpenORB Transaction Service features are :
Management of distributed transactions with a two phase commit
protocol
Sub Transactions management ( nested transactions )
Propagation of the transaction context between CORBA objects
Management of distributed transactions propagation through databases
with the XA protocol
Automatic logs to be able to make recovery in case of failures
Can be used as a transaction initiator or subordinate
High-performance, multiple thread architecture
Developed with POA
Provides a management interface to control all transactions
Full support of JTA
JDBC pooling and automatic resource enlistment
Download
To download the OpenORB Transaction Service, do one of the following :
CVS : you can use CVS to grab the sources directly.
FTP : you get either a CVS snapshot or a prebuilt version
To use one of these possibilities, go to the Download Services page.
ChangeLog
August 15th 2001. Version 1.2.0.
Changed the transaction client side to support late binding to the
transaction monitor.
Bug fixed in the transactional client interceptor. This bug was due to
a change in the OpenORB behavior concerning the slot
To get previous change log, please refer to the CHANGELOG file available
within this service distribution."
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
From pgsql-hackers-owner+M45244@postgresql.org Sat Oct 11 01:23:16 2003
Return-path: <pgsql-hackers-owner+M45244@postgresql.org>
Received: from svr5.postgresql.org (svr5.postgresql.org [64.117.225.181])
by candle.pha.pa.us (8.11.6/8.11.6) with ESMTP id h9B5NFd23659
for <pgman@candle.pha.pa.us>; Sat, 11 Oct 2003 01:23:15 -0400 (EDT)
Received: from postgresql.org (svr1.postgresql.org [64.117.224.193])
by svr5.postgresql.org (Postfix) with ESMTP
id A052972E6E6; Sat, 11 Oct 2003 05:23:07 +0000 (GMT)
X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org
Received: from localhost (unknown [64.117.224.130])
by svr1.postgresql.org (Postfix) with ESMTP id 7E090D1B4E1
for <pgsql-hackers-postgresql.org@localhost.postgresql.org>; Sat, 11 Oct 2003 05:22:45 +0000 (GMT)
Received: from svr1.postgresql.org ([64.117.224.193])
by localhost (neptune.hub.org [64.117.224.130]) (amavisd-new, port 10024)
with ESMTP id 87418-02
for <pgsql-hackers-postgresql.org@localhost.postgresql.org>;
Sat, 11 Oct 2003 02:22:03 -0300 (ADT)
Received: from voyager.corporate.connx.com (voyager.corporate.connx.com [65.212.159.131])
by svr1.postgresql.org (Postfix) with ESMTP id 1756CD1B4FC
for <pgsql-hackers@postgresql.org>; Sat, 11 Oct 2003 02:21:58 -0300 (ADT)
Content-Class: urn:content-classes:message
Subject: Re: [HACKERS] 2-phase commit
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Date: Fri, 10 Oct 2003 22:22:03 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Message-ID: <D90A5A6C612A39408103E6ECDD77B8294CE1EE@voyager.corporate.connx.com>
Thread-Topic: [HACKERS] 2-phase commit
Thread-Index: AcOPp2jLw1yNPbdnRFGP5HwssCpXCwACbcFwAAGb7AA=
From: "Dann Corbit" <DCorbit@connx.com>
To: "Dann Corbit" <DCorbit@connx.com>, "Christopher Browne" <cbbrowne@acm.org>,
<pgsql-hackers@postgresql.org>
X-Virus-Scanned: by amavisd-new at postgresql.org
X-Mailing-List: pgsql-hackers
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by candle.pha.pa.us id h9B5NFd23659
Status: OR
Here is a sourceforge version of the same thing
http://openorb.sourceforge.net/
> -----Original Message-----
> From: Dann Corbit
> Sent: Friday, October 10, 2003 9:38 PM
> To: Christopher Browne; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] 2-phase commit
>
>
> Why not apply the effort to something already done and
> compatibly licensed?
>
> This:
> http://dog.intalio.com/ots.html
>
> Appears to be a Berkeley style licensed:
> http://dog.intalio.com/license.html
>
> Transaction monitor.
>
> "Overview
> The OpenORB Transaction Service is a very scalable
> transaction monitor which also provides several extensions
> like XA management, a management interface to control all
> transaction processes and a high reliable recovery system.
>
> By coordinating OpenORB and OpenORB Transaction Service, you
> provide a reliable and powerful foundation for building large
> scalable distributed applications.
>
> Datasheet
> The OpenORB Transaction Service is a fully compliant
> implementation of the OMG Transaction Service specification.
> The OpenORB Transaction Service features are :
> Management of distributed transactions with a two phase
> commit protocol
> Sub Transactions management ( nested transactions )
> Propagation of the transaction context between CORBA objects
> Management of distributed transactions propagation through
> databases with the XA protocol
> Automatic logs to be able to make recovery in case of failures
> Can be used as a transaction initiator or subordinate
> High-performance, multiple thread architecture
> Developed with POA
> Provides a management interface to control all transactions
> Full support of JTA
> JDBC pooling and automatic resource enlistment
>
>
> Download
> To download the OpenORB Transaction Service, do one of the
> following :
> CVS : you can use CVS to grab the sources directly.
> FTP : you get either a CVS snapshot or a prebuilt version
> To use one of these possibilities, go to the Download Services page.
>
> ChangeLog
> August 15th 2001. Version 1.2.0.
> Changed the transaction client side to support late binding
> to the transaction monitor.
> Bug fixed in the transactional client interceptor. This bug
> was due to a change in the OpenORB behavior concerning the slot
>
>
> To get previous change log, please refer to the CHANGELOG
> file available within this service distribution."
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
http://www.postgresql.org/docs/faqs/FAQ.html
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
From pgsql-hackers-owner+M45247@postgresql.org Sat Oct 11 08:38:03 2003
Return-path: <pgsql-hackers-owner+M45247@postgresql.org>
Received: from svr4.postgresql.org (svr4.postgresql.org [64.117.224.192])
by candle.pha.pa.us (8.11.6/8.11.6) with ESMTP id h9BCc1d20782
for <pgman@candle.pha.pa.us>; Sat, 11 Oct 2003 08:38:01 -0400 (EDT)
Received: from postgresql.org (svr1.postgresql.org [64.117.224.193])
by svr4.postgresql.org (Postfix) with ESMTP
id E4FAE1CB46A9; Sat, 11 Oct 2003 12:37:48 +0000 (GMT)
X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org
Received: from localhost (unknown [64.117.224.130])
by svr1.postgresql.org (Postfix) with ESMTP id 8A364D1B4EF
for <pgsql-hackers-postgresql.org@localhost.postgresql.org>; Sat, 11 Oct 2003 12:37:37 +0000 (GMT)
Received: from svr1.postgresql.org ([64.117.224.193])
by localhost (neptune.hub.org [64.117.224.130]) (amavisd-new, port 10024)
with ESMTP id 48999-05
for <pgsql-hackers-postgresql.org@localhost.postgresql.org>;
Sat, 11 Oct 2003 09:36:55 -0300 (ADT)
Received: from smtpzilla2.xs4all.nl (smtpzilla2.xs4all.nl [194.109.127.138])
by svr1.postgresql.org (Postfix) with ESMTP id 0F175D1B4E1
for <pgsql-hackers@postgresql.org>; Sat, 11 Oct 2003 09:36:47 -0300 (ADT)
Received: from xs1.xs4all.nl (xs1.xs4all.nl [194.109.3.11])
by smtpzilla2.xs4all.nl (8.12.9/8.12.9) with ESMTP id h9BCaQMW052048;
Sat, 11 Oct 2003 14:36:30 +0200 (CEST)
Received: from xs1.xs4all.nl (jtv@localhost.xs4all.nl [127.0.0.1])
by xs1.xs4all.nl (8.12.10/8.12.9) with ESMTP id h9BCaPpX097890;
Sat, 11 Oct 2003 14:36:25 +0200 (CEST)
(envelope-from jtv@xs4all.nl)
Received: (from jtv@localhost)
by xs1.xs4all.nl (8.12.10/8.12.9/Submit) id h9BCaPPT097880;
Sat, 11 Oct 2003 14:36:25 +0200 (CEST)
(envelope-from jtv)
Date: Sat, 11 Oct 2003 14:36:25 +0200
From: "Jeroen T. Vermeulen" <jtv@xs4all.nl>
To: Dann Corbit <DCorbit@connx.com>
cc: Christopher Browne <cbbrowne@acm.org>, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] 2-phase commit
Message-ID: <20031011123624.GA97612@xs4all.nl>
Mail-Followup-To: Dann Corbit <DCorbit@connx.com>,
Christopher Browne <cbbrowne@acm.org>, pgsql-hackers@postgresql.org
References: <D90A5A6C612A39408103E6ECDD77B8294CE1EC@voyager.corporate.connx.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <D90A5A6C612A39408103E6ECDD77B8294CE1EC@voyager.corporate.connx.com>
User-Agent: Mutt/1.4.1i
X-Virus-Scanned: by amavisd-new at postgresql.org
X-Mailing-List: pgsql-hackers
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org
Status: OR
On Fri, Oct 10, 2003 at 09:37:53PM -0700, Dann Corbit wrote:
> Why not apply the effort to something already done and compatibly
> licensed?
>
> This:
> http://dog.intalio.com/ots.html
>
> Appears to be a Berkeley style licensed:
> http://dog.intalio.com/license.html
>
> Transaction monitor.
I'd say this is complementary, not an alternative to 2PC implementation
issues.
The transaction monitor lives on the other side of the problem. 2PC is
needed in the database _so that_ the transaction monitor can do its job.
That said, having a 3-tier model is probably a good idea if distributed
transaction management is what we want. :-)
Jeroen
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly
From pgsql-hackers-owner+M45298@postgresql.org Mon Oct 13 15:55:48 2003
Return-path: <pgsql-hackers-owner+M45298@postgresql.org>
Received: from www.postgresql.com (209.204.46.200.psinetpa.net [200.46.204.209] (may be forged))
by candle.pha.pa.us (8.11.6/8.11.6) with ESMTP id h9DJtkd05408
for <pgman@candle.pha.pa.us>; Mon, 13 Oct 2003 15:55:47 -0400 (EDT)
Received: from postgresql.org (svr1.postgresql.org [200.46.204.71])
by www.postgresql.com (Postfix) with ESMTP
id B7324CF5197; Mon, 13 Oct 2003 16:55:34 -0300 (ADT)
X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org
Received: from localhost (unknown [200.46.204.2])
by svr1.postgresql.org (Postfix) with ESMTP id CCFF7D1B4FE
for <pgsql-hackers-postgresql.org@localhost.postgresql.org>; Mon, 13 Oct 2003 19:55:32 +0000 (GMT)
Received: from svr1.postgresql.org ([200.46.204.71])
by localhost (neptune.hub.org [200.46.204.2]) (amavisd-new, port 10024)
with ESMTP id 16288-06
for <pgsql-hackers-postgresql.org@localhost.postgresql.org>;
Mon, 13 Oct 2003 16:55:01 -0300 (ADT)
Received: from voyager.corporate.connx.com (voyager.corporate.connx.com [65.212.159.131])
by svr1.postgresql.org (Postfix) with ESMTP id 0636BD1B532
for <pgsql-hackers@postgresql.org>; Mon, 13 Oct 2003 16:54:58 -0300 (ADT)
Content-Class: urn:content-classes:message
Subject: Re: [HACKERS] 2-phase commit
Date: Mon, 13 Oct 2003 12:54:53 -0700
MIME-Version: 1.0
Content-Type: text/plain;
charset="us-ascii"
Message-ID: <D90A5A6C612A39408103E6ECDD77B829408BF5@voyager.corporate.connx.com>
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Thread-Topic: [HACKERS] 2-phase commit
Thread-Index: AcOP9Fpw1EtLlhHkTKKwePp/YkaQTgBzmnCQ
From: "Dann Corbit" <DCorbit@connx.com>
To: "Jeroen T. Vermeulen" <jtv@xs4all.nl>
cc: "Christopher Browne" <cbbrowne@acm.org>, <pgsql-hackers@postgresql.org>
X-Virus-Scanned: by amavisd-new at postgresql.org
X-Mailing-List: pgsql-hackers
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by candle.pha.pa.us id h9DJtkd05408
Status: OR
> -----Original Message-----
> From: Jeroen T. Vermeulen [mailto:jtv@xs4all.nl]
> Sent: Saturday, October 11, 2003 5:36 AM
> To: Dann Corbit
> Cc: Christopher Browne; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] 2-phase commit
>
>
> On Fri, Oct 10, 2003 at 09:37:53PM -0700, Dann Corbit wrote:
> > Why not apply the effort to something already done and compatibly
> > licensed?
> >
> > This:
> > http://dog.intalio.com/ots.html
> >
> > Appears to be a Berkeley style licensed:
> > http://dog.intalio.com/license.html
> >
> > Transaction monitor.
>
> I'd say this is complementary, not an alternative to 2PC
> implementation issues.
My notion is that the specification has been created that describes how
the system should operate, what the API's are, etc. I think that most
of the work is involved in that area. The notion is that if you program
to this spec, it will already have been well thought out and it should
be standards based when completed.
> The transaction monitor lives on the other side of the
> problem. 2PC is needed in the database _so that_ the
> transaction monitor can do its job.
Theoretically, if any database in the chain supports 2PC, you could make
all connected systems 2PC compliant by using the one functional system
as a persistent store. But you are right. PostgreSQL still would need
the "I promise to commit when you ask" method if it is to really support
it.
I think another way it could be handled is with nested transactions.
Just have the promise phase be an inner transaction commit but have an
outer transaction bracket that one for the actual commit.
> That said, having a 3-tier model is probably a good idea if
> distributed transaction management is what we want. :-)
In real life, I think it is _always_ done this way.
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
From pgsql-hackers-owner+M45310@postgresql.org Mon Oct 13 20:18:25 2003
Return-path: <pgsql-hackers-owner+M45310@postgresql.org>
Received: from www.postgresql.com (209.204.46.200.psinetpa.net [200.46.204.209] (may be forged))
by candle.pha.pa.us (8.11.6/8.11.6) with ESMTP id h9E0IMd02430
for <pgman@candle.pha.pa.us>; Mon, 13 Oct 2003 20:18:23 -0400 (EDT)
Received: from postgresql.org (svr1.postgresql.org [200.46.204.71])
by www.postgresql.com (Postfix) with ESMTP
id 16454CF7280; Mon, 13 Oct 2003 21:18:12 -0300 (ADT)
X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org
Received: from localhost (unknown [200.46.204.2])
by svr1.postgresql.org (Postfix) with ESMTP id F411ED1B538
for <pgsql-hackers-postgresql.org@localhost.postgresql.org>; Tue, 14 Oct 2003 00:18:09 +0000 (GMT)
Received: from svr1.postgresql.org ([200.46.204.71])
by localhost (neptune.hub.org [200.46.204.2]) (amavisd-new, port 10024)
with ESMTP id 73033-02
for <pgsql-hackers-postgresql.org@localhost.postgresql.org>;
Mon, 13 Oct 2003 21:17:39 -0300 (ADT)
Received: from mail.hive.nj2.inquent.com (mc.carriermail.com [205.178.180.9])
by svr1.postgresql.org (Postfix) with SMTP id BA9E8D1B575
for <pgsql-hackers@postgresql.org>; Mon, 13 Oct 2003 21:17:37 -0300 (ADT)
Received: (qmail 6743 invoked from network); 14 Oct 2003 00:10:32 -0000
Received: from unknown (HELO ?192.168.1.199?) (134.22.69.154)
by 205.178.180.9 with SMTP; 14 Oct 2003 00:10:32 -0000
Subject: Re: [HACKERS] 2-phase commit
From: Rod Taylor <rbt@rbt.ca>
To: Dann Corbit <DCorbit@connx.com>
cc: "Jeroen T. Vermeulen" <jtv@xs4all.nl>,
Christopher Browne <cbbrowne@acm.org>,
PostgreSQL Development <pgsql-hackers@postgresql.org>
In-Reply-To: <D90A5A6C612A39408103E6ECDD77B829408BF5@voyager.corporate.connx.com>
References: <D90A5A6C612A39408103E6ECDD77B829408BF5@voyager.corporate.connx.com>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-b4H+7106Ap3EF98tkvjh"
Message-ID: <1066090267.46588.14.camel@jester>
MIME-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5
Date: Mon, 13 Oct 2003 20:11:08 -0400
X-Virus-Scanned: by amavisd-new at postgresql.org
X-Mailing-List: pgsql-hackers
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org
Status: OR
--=-b4H+7106Ap3EF98tkvjh
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
> I think another way it could be handled is with nested transactions.
> Just have the promise phase be an inner transaction commit but have an
> outer transaction bracket that one for the actual commit.
Not really. In the event of a crash, most 2PC systems will expect the
participant to come back in the same state it crashed in.
Our nested-transaction implementation (like our standard transaction
implementation) aborts all transactions on crash.
--=-b4H+7106Ap3EF98tkvjh
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)
iD8DBQA/iz8a6DETLow6vwwRAs9mAJ0VLew5oH18eL/7BArqWj0H7pYJAwCePLbQ
hpvlKlmUIzIA38T5R62+Ts8=
=xuTB
-----END PGP SIGNATURE-----
--=-b4H+7106Ap3EF98tkvjh--
From pgsql-hackers-owner+M45319@postgresql.org Mon Oct 13 22:15:41 2003
Return-path: <pgsql-hackers-owner+M45319@postgresql.org>
Received: from svr4.postgresql.org (70.204.46.200.psinetpa.net [200.46.204.70] (may be forged))
by candle.pha.pa.us (8.11.6/8.11.6) with ESMTP id h9E2Fbd17197
for <pgman@candle.pha.pa.us>; Mon, 13 Oct 2003 22:15:38 -0400 (EDT)
Received: from postgresql.org (svr1.postgresql.org [200.46.204.71])
by svr4.postgresql.org (Postfix) with ESMTP
id B2DC01CB4910; Tue, 14 Oct 2003 02:15:27 +0000 (GMT)
X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org
Received: from localhost (unknown [200.46.204.2])
by svr1.postgresql.org (Postfix) with ESMTP id 22899D1B538
for <pgsql-hackers-postgresql.org@localhost.postgresql.org>; Tue, 14 Oct 2003 02:15:24 +0000 (GMT)
Received: from svr1.postgresql.org ([200.46.204.71])
by localhost (neptune.hub.org [200.46.204.2]) (amavisd-new, port 10024)
with ESMTP id 92845-02
for <pgsql-hackers-postgresql.org@localhost.postgresql.org>;
Mon, 13 Oct 2003 23:14:54 -0300 (ADT)
Received: from snipe.mail.pas.earthlink.net (snipe.mail.pas.earthlink.net [207.217.120.62])
by svr1.postgresql.org (Postfix) with ESMTP id 6C8F3D1B515
for <pgsql-hackers@postgresql.org>; Mon, 13 Oct 2003 23:14:52 -0300 (ADT)
Received: from dialup-65.58.151.117.dial1.pittsburgh1.level3.net ([65.58.151.117])
by snipe.mail.pas.earthlink.net with esmtp (Exim 3.33 #1)
id 1A9Ehw-0004TJ-00; Mon, 13 Oct 2003 19:14:45 -0700
From: Jordan Henderson <jordan_henders@yahoo.com>
To: Rod Taylor <rbt@rbt.ca>, Dann Corbit <DCorbit@connx.com>
Subject: Re: [HACKERS] 2-phase commit
Date: Mon, 13 Oct 2003 22:13:53 -0400
User-Agent: KMail/1.5.3
cc: "Jeroen T. Vermeulen" <jtv@xs4all.nl>,
Christopher Browne <cbbrowne@acm.org>,
PostgreSQL Development <pgsql-hackers@postgresql.org>
References: <D90A5A6C612A39408103E6ECDD77B829408BF5@voyager.corporate.connx.com> <1066090267.46588.14.camel@jester>
In-Reply-To: <1066090267.46588.14.camel@jester>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-ID: <200310132213.53751.jordan_henders@yahoo.com>
X-Virus-Scanned: by amavisd-new at postgresql.org
X-Mailing-List: pgsql-hackers
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org
Status: OR
On Monday 13 October 2003 20:11, Rod Taylor wrote:
> > I think another way it could be handled is with nested transactions.
> > Just have the promise phase be an inner transaction commit but have an
> > outer transaction bracket that one for the actual commit.
>
> Not really. In the event of a crash, most 2PC systems will expect the
> participant to come back in the same state it crashed in.
>
Yes, this is correct. There are certain phases of the protocol in which the
transaction state must be re-instated from the log file after a crash of the
DB server. The re-instatement must occur prior to any connections being
accepted by the server. Additionally, the coordinator must be fully
recoverable as well. The coordinator may, depending on the phase of the
commit/abort, contact child servers after it crashes. The requirement is
that during log replay, the transaction structures might have to be fully
reconstructed and remain in-place after log replay has completed, until the
disposition of the (sub)transaction is settled by the coordinator. All
dependent on the phase of course.
> Our nested-transaction implementation (like our standard transaction
> implementation) aborts all transactions on crash.
Jordan Henderson
---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend
From JanWieck@Yahoo.com Tue Oct 14 00:21:11 2003
Return-path: <JanWieck@Yahoo.com>
Received: from smtp017.mail.yahoo.com (smtp017.mail.yahoo.com [216.136.174.114])
by candle.pha.pa.us (8.11.6/8.11.6) with SMTP id h9E4L8d06728
for <pgman@candle.pha.pa.us>; Tue, 14 Oct 2003 00:21:09 -0400 (EDT)
Received: from pcp01341166pcs.wilog301.pa.comcast.net (HELO europa.janwieck.net) (janwieck@68.80.245.191 with login)
by smtp.mail.vip.sc5.yahoo.com with SMTP; 14 Oct 2003 04:21:03 -0000
Received: from Yahoo.com (pcp01341166pcs.wilog301.pa.comcast.net [68.80.245.191])
(authenticated)
by europa.janwieck.net (8.11.6/8.11.6) with ESMTP id h9E4L1311359;
Tue, 14 Oct 2003 00:21:01 -0400
Message-ID: <3F8B7990.60207@Yahoo.com>
Date: Tue, 14 Oct 2003 00:20:32 -0400
From: Jan Wieck <JanWieck@Yahoo.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Tatsuo Ishii <t-ishii@sra.co.jp>, andrew@libertyrms.info,
pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] 2-phase commit
References: <200310100053.h9A0rkl23681@candle.pha.pa.us>
In-Reply-To: <200310100053.h9A0rkl23681@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Status: OR
Bruce Momjian wrote:
> Tatsuo Ishii wrote:
>> > Yes. I don't think that 2PC is a solution for robustness in face of
>> > network failure. It's too slow, to begin with. Some sort of
>> > multi-master system is very desirable for network failures, &c., but
>> > I don't think anybody does active/hot standby with 2PC any more; the
>> > performance is too bad.
>>
>> I'm tired of this kind of "2PC is too slow" arguments. I think
>> Satoshi, the only guy who made a trial implementation of 2PC for
>> PostgreSQL, has already showed that 2PC is not that slow.
>
> Agreed. Let's get it into 7.5 and see it in action. If we need to
> adjust it, we can, but right now, we need something for distributed
> transactions, and this seems like the logical direction.
>
Are you guy's kidding or what?
2PC is not too slow in normal operations when everything is purring like
little kittens and you're just wasting your excess bandwidth on it. The
point is that it behaves horrible and like a dirty backstreet cat at the
time when things go wrong ... basically it's a neat thing to have, but
from the second you need it it becomes useless.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #
From peter.galbavy@knowtion.net Tue Oct 14 05:00:23 2003
Return-path: <peter.galbavy@knowtion.net>
Received: from mailstore-1.mail.knowledge.com ([213.170.2.69])
by candle.pha.pa.us (8.11.6/8.11.6) with ESMTP id h9E90Ld00955
for <pgman@candle.pha.pa.us>; Tue, 14 Oct 2003 05:00:23 -0400 (EDT)
Received: from [213.155.153.61] (helo=MBLOXD98BTT0J)
by mailstore-1.mail.knowledge.com with asmtp (Exim 3.36 #1)
id 1A9L2A-0004lK-00; Tue, 14 Oct 2003 10:00:02 +0100
Message-ID: <004601c39231$8db3f5e0$2f28a8c0@cblan.mblox.com>
From: "Peter Galbavy" <peter.galbavy@knowtion.net>
To: "Jan Wieck" <JanWieck@Yahoo.com>, "Bruce Momjian" <pgman@candle.pha.pa.us>
cc: "Tatsuo Ishii" <t-ishii@sra.co.jp>, <andrew@libertyrms.info>,
<pgsql-hackers@postgresql.org>
References: <200310100053.h9A0rkl23681@candle.pha.pa.us> <3F8B7990.60207@Yahoo.com>
Subject: Re: [HACKERS] 2-phase commit
Date: Tue, 14 Oct 2003 09:59:58 +0100
Organization: Knowtion Ltd.
MIME-Version: 1.0
Content-Type: text/plain;
charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Status: OR
Jan Wieck wrote:
> 2PC is not too slow in normal operations when everything is purring
> like little kittens and you're just wasting your excess bandwidth on
> it. The point is that it behaves horrible and like a dirty backstreet
> cat at the time when things go wrong ... basically it's a neat thing
> to have, but from the second you need it it becomes useless.
I can't see anyone being forced to use it once it maybe/is supported. Like
many tools, "ouch!" is a good reaction when used untrained/incorrectly.
Peter
Reference in New Issue View Git Blame Copy Permalink