diff --git a/doc/TODO.detail/2phase b/doc/TODO.detail/2phase new file mode 100644 index 0000000000..aaf089007b --- /dev/null +++ b/doc/TODO.detail/2phase @@ -0,0 +1,2161 @@ +From pgsql-hackers-owner+M49851=pgman=candle.pha.pa.us@postgresql.org Sat Feb 7 10:33:51 2004 +Return-path: +Received: from postgresql.org (svr1.postgresql.org [200.46.204.71]) + by candle.pha.pa.us (8.11.6/8.11.6) with ESMTP id i17HXbr05526 + for ; Sat, 7 Feb 2004 12:33:50 -0500 (EST) +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 0FDCBD1D8A0 + for ; Wed, 4 Feb 2004 20:22:23 +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 35031-10 + for ; + Wed, 4 Feb 2004 16:22:21 -0400 (AST) +Received: from main.gmane.org (main.gmane.org [80.91.224.249]) + by svr1.postgresql.org (Postfix) with ESMTP id D9726D1D85F + for ; Wed, 4 Feb 2004 16:22:20 -0400 (AST) +Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) + id 1AoTXQ-0006tA-00 + for ; Wed, 04 Feb 2004 21:22:20 +0100 +Received: from kosh.hut.fi ([130.233.228.10]) + by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) + id 1AlnuQ-0007hv-00 + for ; Wed Feb 4 20:22:20 2004 +Received: from hlinnaka by kosh.hut.fi with local (Gmexim 0.1 (Debian)) + id 1AlnuQ-0007hv-00 + for ; Wed Feb 4 20:22:20 2004 +X-Injected-Via-Gmane: http://gmane.org/ +To: pgsql-hackers@postgresql.org +From: Heikki Linnakangas +Subject: [HACKERS] Two-phase commit +Date: Wed, 4 Feb 2004 22:22:16 +0200 +Lines: 30 +Message-ID: +MIME-Version: 1.0 +Content-Type: TEXT/PLAIN; charset=US-ASCII +X-Complaints-To: usenet@sea.gmane.org +X-Gmane-NNTP-Posting-Host: kosh.hut.fi +X-X-Sender: hlinnaka@kosh.hut.fi +X-Virus-Scanned: by amavisd-new at postgresql.org +X-Mailing-List: pgsql-hackers +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on + candle.pha.pa.us +X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham + version=2.61 +Status: ORr + +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 transaction, you first do a BEGIN and your updates as +usual. At the end of the transaction, you call PREPCOMMIT 'foobar' instead +of COMMIT. Now the transaction is in prepared state, ready to commit at a +later time. 'foobar' is the global transaction identifier assigned for the +transaction. + +Later, when you want to finish the second phase, you call +COMMITPREPARED 'foobar'; + +There is a system view pg_prepared_xacts that gives you all transactions +that are in prepared state waiting for COMMITPREPARED or ABORTPREPARED. + +I have also done some work on XA-enabling the JDBC drivers, now that we +have what it takes in the server side. I have succesfully executed +2PC transactions with JBossMQ and Postgres, using JBoss as the +transaction manager, so the basic stuff seems to be working. + +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? + +- Heikki + + +---------------------------(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+M50166=pgman=candle.pha.pa.us@postgresql.org Sun Feb 15 14:10:46 2004 +Return-path: +Received: from postgresql.org (svr1.postgresql.org [200.46.204.71]) + by candle.pha.pa.us (8.11.6/8.11.6) with ESMTP id i1FLAir14581 + for ; Sun, 15 Feb 2004 16:10:45 -0500 (EST) +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 297AAD1CAF3 + for ; Mon, 9 Feb 2004 20:09:53 +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 07202-01 + for ; + Mon, 9 Feb 2004 16:09:37 -0400 (AST) +Received: from smtp-4.hut.fi (smtp-4.hut.fi [130.233.228.94]) + by svr1.postgresql.org (Postfix) with ESMTP id 90D81D1C4BC + for ; Mon, 9 Feb 2004 16:09:34 -0400 (AST) +Received: from kosh.hut.fi (kosh.hut.fi [130.233.228.10]) + by smtp-4.hut.fi (8.12.10/8.12.10) with ESMTP id i19K9Y66012417; + Mon, 9 Feb 2004 22:09:34 +0200 +Date: Mon, 9 Feb 2004 22:09:34 +0200 (EET) +From: Heikki Linnakangas +X-X-Sender: hlinnaka@kosh.hut.fi +To: "Jeroen T. Vermeulen" +cc: PostgreSQL Development +Subject: Re: [HACKERS] Two-phase commit +In-Reply-To: <20040208195332.GE25140@xs4all.nl> +Message-ID: +References: + <20040208195332.GE25140@xs4all.nl> +MIME-Version: 1.0 +Content-Type: TEXT/PLAIN; charset=US-ASCII +X-RAVMilter-Version: 8.4.3(snapshot 20030212) (smtp-4.hut.fi) +X-Virus-Scanned: by amavisd-new at postgresql.org +X-Mailing-List: pgsql-hackers +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on + candle.pha.pa.us +X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham + version=2.61 +Status: OR + +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 gotten so far with this... One question: can I +> check for this view to see if 2PC is supported before issuing the new +> kind of commit? I'm interested in supporting 2PC even for some regular +> transactions to reduce their in-doubt window, but I don't want to issue a +> command at the last moment that may fail (and thereby abort) because the +> backend version I'm connected to doesn't support the new command! + +Yes, I suppose that would work. Though you would have to use a query that +wouldn't fail in case the view doesn't exist, otherwise you end up +aborting the transaction anyway. This should work: + +SELECT COUNT(*) FROM pg_views WHERE schemanem='pg_catalog' AND viewname +='pg_prepared_xacts' + +If it returns 1, you can do 2PC, if it returns 0, you have to regular +commit. + +However, if this gets into 7.5, I guess you could just check for the +version of the backend instead with "SELECT version()". + +- Heikki + +---------------------------(end of broadcast)--------------------------- +TIP 4: Don't 'kill -9' the postmaster + +From pgsql-hackers-owner+M49946=pgman=candle.pha.pa.us@postgresql.org Mon Feb 9 14:18:20 2004 +Return-path: +Received: from postgresql.org (svr1.postgresql.org [200.46.204.71]) + by candle.pha.pa.us (8.11.6/8.11.6) with ESMTP id i19LIHr27947 + for ; Mon, 9 Feb 2004 16:18:18 -0500 (EST) +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 5B8CBD1C9E1 + for ; Mon, 9 Feb 2004 21:00:06 +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 25216-09 + for ; + Mon, 9 Feb 2004 16:59:56 -0400 (AST) +Received: from smtp-out4.xs4all.nl (smtp-out4.xs4all.nl [194.109.24.5]) + by svr1.postgresql.org (Postfix) with ESMTP id 0381AD1C4BC + for ; Mon, 9 Feb 2004 16:59:53 -0400 (AST) +Received: from xs1.xs4all.nl (xs1.xs4all.nl [194.109.21.2]) + by smtp-out4.xs4all.nl (8.12.10/8.12.10) with ESMTP id i19Kw1Oh062440; + Mon, 9 Feb 2004 21:59:41 +0100 (CET) +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 i19KuUBT033906; + Mon, 9 Feb 2004 21:56:30 +0100 (CET) + (envelope-from jtv@xs4all.nl) +Received: (from jtv@localhost) + by xs1.xs4all.nl (8.12.10/8.12.9/Submit) id i19KuUgt033905; + Mon, 9 Feb 2004 21:56:30 +0100 (CET) + (envelope-from jtv) +Date: Mon, 9 Feb 2004 21:56:30 +0100 +From: "Jeroen T. Vermeulen" +To: Heikki Linnakangas +cc: PostgreSQL Development +Subject: Re: [HACKERS] Two-phase commit +Message-ID: <20040209205629.GB13454@xs4all.nl> +Mail-Followup-To: Heikki Linnakangas , + PostgreSQL Development +References: <20040208195332.GE25140@xs4all.nl> +MIME-Version: 1.0 +Content-Type: text/plain; charset=us-ascii +Content-Disposition: inline +In-Reply-To: +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 +X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on + candle.pha.pa.us +X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham + version=2.61 +Status: OR + +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 want to do in libpqxx that may depend on +the Postgres version... + +Thanks! + + +---------------------------(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+M50540=pgman=candle.pha.pa.us@postgresql.org Sat Feb 28 14:40:52 2004 +Return-path: +Received: from postgresql.org (svr1.postgresql.org [200.46.204.71]) + by candle.pha.pa.us (8.11.6/8.11.6) with ESMTP id i1SLeoD13679 + for ; Sat, 28 Feb 2004 16:40:50 -0500 (EST) +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 A0F5BD1E1AA + for ; Sun, 22 Feb 2004 02:27:19 +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 92481-04 + for ; + Sat, 21 Feb 2004 22:27:18 -0400 (AST) +Received: from main.gmane.org (main.gmane.org [80.91.224.249]) + by svr1.postgresql.org (Postfix) with ESMTP id 54A72D1E197 + for ; Sat, 21 Feb 2004 22:27:11 -0400 (AST) +Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) + id 1AujKe-0004i5-00 + for ; Sun, 22 Feb 2004 03:27:00 +0100 +Received: from kosh.hut.fi ([130.233.228.10]) + by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) + id 1AlnuQ-0007hv-00 + for ; Sun Feb 22 02:27:00 2004 +Received: from hlinnaka by kosh.hut.fi with local (Gmexim 0.1 (Debian)) + id 1AlnuQ-0007hv-00 + for ; Sun Feb 22 02:27:00 2004 +X-Injected-Via-Gmane: http://gmane.org/ +To: pgsql-hackers@postgresql.org +From: Heikki Linnakangas +Subject: Re: [HACKERS] Two-phase commit +Date: Sun, 22 Feb 2004 04:26:56 +0200 +Lines: 70 +Message-ID: +References: + <200402080138.i181cPl15259@candle.pha.pa.us> +MIME-Version: 1.0 +Content-Type: TEXT/PLAIN; charset=US-ASCII +X-Complaints-To: usenet@sea.gmane.org +X-Gmane-NNTP-Posting-Host: kosh.hut.fi +X-X-Sender: hlinnaka@kosh.hut.fi +In-Reply-To: <200402080138.i181cPl15259@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 +X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on + candle.pha.pa.us +X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham + version=2.61 +Status: OR + +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 two-phase commit included. One item that has come up +> in past discussions is a way of recording two-phase commit failures to +> the administrator in cases where you precommit, get a reply, commit, +> then the remote machine disappears. + +You would resolve this by opening a new session, and checking if the gid +you specified in PREPARE TRANSACTION is still present in the +pg_prepared_xacts view. It could be done manually by the administrator, or +it could be done automatically by an external transaction manager if +there is one. + +The XA interface specifies a function called "recover", that gives you a +list of pending transactions. If we some day have an XA implementation, +the recover call would map directly to "SELECT gid FROM +pg_prepared_xacts". The JDBC XA implementation that I'm working on does +that already. + +I have updated my patches, see the URL above. I renamed the commands to +PREPARE TRANSACTION, COMMIT PREPARED and ROLLBACK PREPARED. I think it's +more coherent that way. + +I also added documentation entries for the commands, and a basic +regression test. + +I went through all the AtCommit_* and AtEOXact* hooks in xact.c to find +any possible problem areas. The following items have not yet been +implemented and throw an error if you try to do 2PC in the same +transaction. + +* Notifications (NOTIFY/LISTEN). All pending notifications should be +stored in persistent storage in the prepare phase, and sent in the commit +phase. + +* Creation/deletion of relations. I couldn't figure out how the relation +cache invalidation stuff should work with 2PC. + +* Modifying GUC variables. I need to study the GUC code more thoroughly +before I can tell what needs to be done. + +* Updates to shadow/group files, that is, CREATE USER and friends. Needs +some tricks to delay the writing of pg_pwd/pg_group. + +* Large objects. AFAICS, no particular problem here, but I'd like to deal +with them later when the more important stuff are ok. + +Plus a couple of minor details: + +* Temporary tables. The seem to work somehow, but I haven't tested them +much. I have a feeling that nasty things might happen if you commit the +prepared transaction from another backend etc. + +* initdb gives a warning about a missing file. It's harmless, but I +don't see how to detect that you're running under initdb. Also, if you +try to prapare a transaction with a global transaction identifier that's +already in use, you first get a warning and then an error. + +I'm going to tackle the above problems later, but I would like to get +this applied to the cvs trunk with the current functionality first, after +discussion of course. The rest are nice to have for the sake of +completeness but probably not necessary for most users. + +- Heikki + + +---------------------------(end of broadcast)--------------------------- +TIP 5: Have you checked our extensive FAQ? + + http://www.postgresql.org/docs/faqs/FAQ.html + +From pgsql-general-owner+M58726=pgman=candle.pha.pa.us@postgresql.org Fri Mar 19 01:00:58 2004 +Return-path: +Received: from postgresql.org (svr1.postgresql.org [200.46.204.71]) + by candle.pha.pa.us (8.11.6/8.11.6) with ESMTP id i2J80ud15620 + for ; Fri, 19 Mar 2004 03:00:57 -0500 (EST) +X-Original-To: pgsql-general-postgresql.org@localhost.postgresql.org +Received: from localhost (unknown [200.46.204.2]) + by svr1.postgresql.org (Postfix) with ESMTP id 53189D1BB74 + for ; Fri, 19 Mar 2004 07:31:13 +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 87439-01 + for ; + Fri, 19 Mar 2004 03:31:05 -0400 (AST) +Received: from builder.localdomain (unknown [61.94.124.129]) + by svr1.postgresql.org (Postfix) with SMTP id 12CC3D1B80B + for ; Fri, 19 Mar 2004 03:30:59 -0400 (AST) +Received: (qmail 11710 invoked from network); 19 Mar 2004 07:30:55 -0000 +Received: from unknown (HELO zara.6.isreserved.com) (192.168.0.113) + by builder.localdomain with SMTP; 19 Mar 2004 07:30:55 -0000 +Message-ID: <405AA1B0.3080600@zara.6.isreserved.com> +Date: Fri, 19 Mar 2004 14:30:56 +0700 +From: David Garamond +User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031208 +X-Accept-Language: en-us, en +MIME-Version: 1.0 +To: Matthew Hixson +cc: pgsql-general@postgresql.org +Subject: Re: [GENERAL] two phase commit +References: <68FB14C4-7963-11D8-B6BA-000A95D05926@poindextrose.org> +In-Reply-To: <68FB14C4-7963-11D8-B6BA-000A95D05926@poindextrose.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-general +Precedence: bulk +Sender: pgsql-general-owner@postgresql.org +X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on + candle.pha.pa.us +X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham + version=2.61 +Status: OR + +Matthew Hixson wrote: +> From what I can find with Google it looks like TPC might make it into +> Postgrs 7.5. I was wondering if there were any commercial products or +> open source projects that can provide TPC on top of Postgres. Or is +> this something that really needs to be handled by the database itself? + +With the 2PC patch submitted, you can interface with it at the SQL level +(i.e. you prepare, commit, cancel prepare, etc. by issuing ordinary SQL +commands). This means it will be pretty trivial to make it work with +other components like TX manager, etc. For example, I'm guessing it will +be easy to add 2PC support to npgsql (.NET data provider). + +PS: It's really nice to see Postgres coming along feature-wise. 2PC and +nested transaction (aside from native Windows port, of course) are the +main things Firebird has that Potsgres hasn't. After that, we can pretty +much leave FB in the dust... :-) + +-- +dave + +---------------------------(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+M51632@postgresql.org Tue Mar 23 10:18:06 2004 +Return-path: +Received: from postgresql.org (svr1.postgresql.org [200.46.204.71]) + by candle.pha.pa.us (8.11.6/8.11.6) with ESMTP id i2NHI0d16063 + for ; Tue, 23 Mar 2004 12:18:02 -0500 (EST) +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 BFD64D1EBB0; Tue, 23 Mar 2004 16:11:15 +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 35500-05; Tue, 23 Mar 2004 12:11:00 -0400 (AST) +Received: from smtp-4.hut.fi (smtp-4.hut.fi [130.233.228.94]) + by svr1.postgresql.org (Postfix) with ESMTP + id 411C3D1E2D7; Tue, 23 Mar 2004 12:10:58 -0400 (AST) +Received: from kosh.hut.fi (kosh.hut.fi [130.233.228.10]) + by smtp-4.hut.fi (8.12.10/8.12.10) with ESMTP id i2NGAZTZ028569; + Tue, 23 Mar 2004 18:10:45 +0200 +Date: Tue, 23 Mar 2004 18:10:35 +0200 (EET) +From: Heikki Linnakangas +X-X-Sender: hlinnaka@kosh.hut.fi +To: pgsql-hackers@postgresql.org +cc: pgsql-patches@postgresql.org +Subject: Re: [HACKERS] Two-phase commit +In-Reply-To: +Message-ID: +References: + <200402080138.i181cPl15259@candle.pha.pa.us> +MIME-Version: 1.0 +Content-Type: MULTIPART/MIXED; BOUNDARY="182774146-1920606540-1080058235=:513267" +X-RAVMilter-Version: 8.4.3(snapshot 20030212) (smtp-4.hut.fi) +X-Virus-Scanned: by amavisd-new at postgresql.org +X-Mailing-List: pgsql-hackers +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on + candle.pha.pa.us +X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham + version=2.61 +Status: ORr + + This message is in MIME format. The first part should be readable text, + while the remaining parts are likely unreadable without MIME-aware tools. + Send mail to mime@docserver.cac.washington.edu for more info. + +--182774146-1920606540-1080058235=:513267 +Content-Type: TEXT/PLAIN; charset=US-ASCII + +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 personally consider it ready to be applied to cvs tip, but then +again I'm still a newbie :). Please take a look! + +The patch is also available here: http://www.iki.fi/hlinnaka/pgsql/ + +- Heikki +--182774146-1920606540-1080058235=:513267 +Content-Type: APPLICATION/x-gzip; name="twophase_20040321.diff.gz" +Content-Transfer-Encoding: BASE64 +Content-ID: +Content-Description: +Content-Disposition: attachment; filename="twophase_20040321.diff.gz" + +H4sICDIiX0AAA3R3b3BoYXNlXzIwMDQwMzIxLmRpZmYA7Dz7d9pG1j/jv2LC +tgmEl3HixHZsnxKbOGwd2wukSbdfD0eWBtBaSIpGskOb7t++996Z0QMkII/d +pueLm2I0j3vv3LnvGbnnWvz9AbM8syUC+H8yc1oBH/OAuyZv4uPW0ef/bPVP +BmxsO/yAtfzA+xc3Q9Eyb0XgeWHLn4h3TkPw4JYHrRWE1G+3Ah4GNr+13QkL +4JewPZe1m4+fbFn2eMwaEWsE+MgWVtBoNFatsLSzzy68W7azvf2ItfcPdtsH +j56yxjb8lAh6rVZbPb/NXhkBzn/M2nsHu7sHj3fk/K0ffmCN3b36E1aDz6fs +hx+2GPzcN51IhDx4pp682Yy74aWberbDZ1u15OEq4L4RcCse4c+HxrXD9XPA +jZB3JpOAT+BLpvXEEAALCWm3H9fb26zWbu/W2zsxMTPvVs9wvdAez9WDL3Eq +OtTTMDBcYZghsF4NC7iNQhQ/CR7G32+9Gw068Bzn2jBvFDj9uLAwwR0QjsxD +zw29uAG6evki2zIcB0VMfAVSm6WlUHB3dzOCu7vLsmvIk9ss6DzR3YtFF+Dn +ie4iiNXSu/MEpRc+pfQe3gNJtcM5UyLMUj9iDi0zVlZdBL58nJ6jBT1njuzK +n2OHLBcPdekptYUpWrJypoyUMFt56JRm5aHz5zkTsqqXmUBdI0P3FU1GDV3G +Jieb0Kfn4Xbs7ZAK7z3SGhzDQjVm2R8NC7uWkUtlz50gu5anKL7lTVFdy7ux +bDgW54zCpG8Zp7IveThVV94cMBX5vKCuvBloqwpmYFfOFGXC8qaormVuLNq9 +nEkrpFNaxFwqZVfRFDSiBVNGNvTlzVtgYHpejKfIGOfp2Re2yZvhlAb2YsPR +aHFbFr9tuZHjlNrs7wbY6f2n22x7+4D+KcOYa1bzIK6zrtt19Meg0ruozCAm +jcZW7bsrT4RgMwb/OP9uq5Y8IMoIraSBmrJVazRAsmAShiNuGMyZbR2VYVzj +5PLVq97wqt+96vS7pyh/DAfNeGjgdxbPgJ0GS4fT0JvJBWj6G9RZPpbAmIZ2 +2MpMjuHNbGHa7tg7RkIb7NxwJ5Ex4WwA1HIkWtDMeBjS1EqIUiS6xoxb9m0M +FZ9zKaAOPcqPAt8T/FguQDCDpSwKC6dGyO4MwbgRODa4LL1CNvYCFt55DX9q +CK7cBkHXADWRCVnYQkYHHNyM/ea5PI93ZUmaH9gzI5gvL0B3EPwYXMIGMXc9 +X9hC4jzUj/B9ARR7AMN9xzA5+SzTMYQ4KkNX51V32O2XjyeOd204GX7YFq4p +nnT8ADC0UijkkrMkaLrAXrTl2uTun3JhBraPcA9bWiDk2o1AChs7RN4YrrXM +Bt3BVmycLZjtMgIU75tAmWoSmpbCs4DzZy9iJiivOeVgoCHgASANy4uuwzQG +wcaBNwM8nPmTWHFH76FXEBhl8W5tfpdFp3ik2FHEnSsYDPLNA7HAnFsjsJH3 +ji1CxaRbFE7AhpolmwAKCsVGG5x2oaPFDQbkUroIKGKxYVXqOc01+BkCL3Jl +Bt3CGLXHGxPD8jYKfMw115DQncFekRvUqFopXIetLCWHrSUWUFOGURux/cIL ++SLHE8TDKVCqJI/decGNYF4UClhhZk2mB2R4TpM4okWDAGT4IpTshrBUe4ZW +AkTTmW8qLUW2l783Zj6E6OXUutaN1Qa7q54TDmTWf6J0bXET4y2GPZtT77Ic +EICULDwYezAkeHBAHWBHIE+agMzTzrqTPHulZqDNWRqc1eeN9nrAOes4wlvY +bmEjCxAyC+c+2GjbdWyXl5WozfjsmgfHh+8BJIOOG+4q3iquptZcZtCJClQ0 +QPP9sKXArsOhA73YW2QxLHbnwgeLHS8xR8ISLy0fIa5gP3Luw74qkYVOBlqL ++wzYtVZjaLVVO/dM2HetewJ2d+ZZEHJRjFTDz4aHMm9MDlxbt4ipF1BTqBpm +tmvP7N94wwgh+72OQClTww3nzpiLxrsIlDU9Qs9Gr+iGDTAH/kE722YZoRGP +QxZhmwqNUhgsPjYiB7pCq0EhY7nZTJVuTGC8Gsnfo7cHRhuTNIkOsqFhAjbH +g45yKxIBGK1rGfKp9nJmMIdWQqbgdF3rQAZqRZFyUQ70346WC/EWRsyFMz4r +ai6CunHk/ORLRs7KTg37nYtB52TYu7zYOHouNgwKKEtB/ROi6CIqciNpneij +TTCjAFUs4yy+YOScY3Gz0XMu4Z8eQeeA+0tF0bnsiCNpxc1l957ZMYKoymes +M8Y6XpgKi+qF+w5jXI85njuBKQQFWOWZGPRAMGWHUwkH3Rd4lSbrhRSGO9R/ +zVPBEpAjI0SCQnUUmr9BtuAp1PHQ/uX5+fPOyY85g+tYC/KB4fbtUlj2/zxn +WCnOH5MzdFxmBNc2gCNLGkeHlBbg1gcMuQOiAgneFHYFiIJUgSQlbfa/2ixh +FkEcCdIbCYzyXcoVMqlqk71WShXL5PPuWS+tmLBgSFuDkIHh++jsIMe3rMwQ +VozfMEu4SjmAjJy4jMJ2LkSuE6gDkyCYJxg61seNz88nUtJSnELkGuwN04g/ +J4lYKAZlw/v8Ktu35OFb8vDxyUP+kcF/O3UowFqYOBSM/6y0IR/mn1Nu1+HH +Rxfci5Q1J575n6cL+TTkJgu4DBnz/RmV9yWDmM0ectbx6bnDErC/VOawIkxm +q/fwWxH+WxH+qy7Cp9b5WWX4JYu8MswuHL1hkN1PlO5/U43PsV/f6vGfHa5/ +C6f/muE0BpSqUtUyTBNS2pYUo1nrlXHDif9fNpRec49wA4IKLxO29zKXCdt7 +LF4DBtobgM65TPh4O75MCPAxEN8IzuogvL1TfwpR+I66URh6/ug6sh3LsgN2 +xEAu9L8tiBdMJwKf8F0lPapKjNLomtIwbrGtxuXzvw8AhAmi0PSUpZzBN9Ae +EfnwBYMK/CUH4K8otB0B34PZJIBfwgmiprdV+1KQMMilGBeAsi2MgQ7Y4PXz +wc8DalgviESB+dWIoSSnWAj3s0K4zxT9a0RQjlojgPvrBFBDWRa/R+kLrbt0 +oXVXid/ftIxBnC9aGNQ2p8fp5sgFs25R41Ytbi5r3Hp/p+XUJN1LFOX2kHhk +e0ToBZC8tZw7sF832Ink7j+q77HaPt3cRnpLthuWSqXrOYRoHoho6l5lzxp6 +z6G98t62qs+SoWJqj8OcoSR9NJg9ZCfnl2ej573hYHTV7Y/edk6GCMGcGkEJ +vOdDxOeHwbOtWumtbWF+GQl9QiCfnqGAlzoChCisCDng6ChdtRsNhp3h68FI +VvaHEH18+ADw9O3CVVPieAVmsFJp3fDO88s+wK9Kms7fgBO96ZjvIjvglRPY +k5PQaRwjl0Xj+ETGmDikzs7fjLpvT85fD3o/davq1vy2vHLb3t6t78stUMwA +lg7I8Z8HUZ8b1hXsngZfZz48uV6dAX/rYEEiTluip9aOmNxCJLFRasEGqOMW +yqsYePDIoSOTbTzvCI1gwnXfwxbMUIyuVPTWsONjJre6yu7L7cRdxD191Rn8 +WEVWbSP/GsS/j5souV3F7c9sOrBgUzi40FopHnz/iP27sjSIHR5qGMitePQH +wKN2PDMCxgDrms1m4xj5PZJjfhGOF7rer0AdYbjqnHVHp73+8OdnYIID2Ko5 +szyXOElb/Hiv3n4EW7y7XW8/pj0G1dmiyYMpRHoDCJ0qtx5oyhb7HRgI1i8K +3GT3k0HEohXdrMaGd94VmozMJPYHLgZRpND2XDtM0LJSDJA6Ykkr4wQGX8vw +HXJotDplIkSjovHYpc1VmdgbqwJK7lXAIQzjQjEt3aTIW++tyPd9Pd5KklPs +rXay3mqHKfrXeCs5ao232lnnrTSU1d6qTa9ftJ8seivtRygOyfUw75d9j/Yw +AlFDVy3H+YAZDFR3aqZK1cFv8XcRhezYD/+RR32MAV3sUUu/l1OeBmQSaRxB +8uSpr5EbfwXhMuvs4vX5ufz8o07zB5IamIukqrn0Vc6lrwVzUXhhIiqBmkhf +5UT6mjOxARP7nCTKYo/L6d7lTxhfg/HoMWAkckwhoq8SEX1NI6IG0+GGG/mK +0hjh7nqEmfFPPnL80/Xj1+u2DoK/HvWOKSp+wyr7auDuE5asYo2SxwNX6/nu +k3V6ngK0WtX3SY3gc0+qUeshfEBkdnrJLi6HzDTMKddhD9bPI3cMWb2Ywgan +y6n3aBaGCPaYYXSnptzLjZR6FxBbXZ71u4NBFaT6I6ew+/fRqZfWTdHhWxXl +EgO4TCiK2s4rYbqpzu7Teq0hF+FbFc6WMk1xABIjV/HaXptM5t5OfYeOeaRr +BW7WgJkZxD1xldQUHyJVEWcoL+lK3PIFF54uusnS+HJVXKLDKuiBBA4BWzTj +oqiiC3BuDce2aG5rq3bteU5J/kCEE0rK2MS+5e5i8XMJPwEoWGkl084yXAcJ ++F0JQedVb3T5U7ff7512UTCwXcecmTkYHT4HrRXQ6mdgUwSiY6Gx4Qh8lbT0 +B9bAdGtq/Lk3wY1dFINVwgTgCBoqyuLWntpW59oLQuz5tI21bIsZCKKJMKSj +e/RU5o5P622ZCmRwypvVqxlMcVx22a99C4jYYOFx3pRe+ZJQq42WQndVdB1s +9eK/hABTLFvLI20DEfxEDqVEI9b6DTybzuG/tGvbDKc+N99s9Mecmm8EcZ1b +Umfmj/blRdvWw8aX+omFLLU8krS+F4W2y6WbA0N4c8O5j649c2xIB16R4EsH +yYn0XoH60tgTz58H9mQasopZBX7tP2mgP6+z1HH/mTxgOeW33PF8KsqfBV7k +r4H0uM76fIJn7bpw/9oFKx0IfIsSWk5AKWAdrm3EZIFNvRj2XvROOii8cs3f +vYS0lAffJZp3OewOZF8X/F7ugaBY0mMjb5yEktLVylnvtNpkHQa/FRR74mIg +4QEEX/JELJw1AYjYVOTdyVI5QpPpJZRKbzjDraOzX4PuYOaQRw7MwKtlDch5 +vWDOYC8BDZ53NBWcKXq9ArzxOSK6QrBRXN1fVWuTEAIdC9PNg+VLbdiUQisP +KOEflQmuOcxSFhUIxcyKqSsggs1g2+owxDRIFgGOxGXIE0w8+5aCbEW+Y5uw +VRIQkAeMd5WTyXkfh4Qp4HHFAvdJsU9CWLqXl4kB4r0CdSdmNJN9eR6F7A55 +OvciyTPcgMV3dYDm5QNDfUVYkZCcyzKpgvqupKY6jlFxqTg8xT0cq7iqRsPE +uwAvCLt05hsQ49kd7s0t3rnUa3yhoY4dYyJBIIt5vqLUYbE29FCsZIc2aORv +UtgpLKkjbUpHBL34fLdK3rS4qZWJFF97LjDNwquvHhNRcIsCbwYGjqL1i2kU +Wt6dK+qkEn4m+syohGYj5uWSVJ8HgFZWCCk71kIqc3QhgWCaiZYSr/vAeLl6 +HxwANtJr/SiChIKHJpgAIIMMKQmNYkIyF1mmNkRe2eXsTeecQUcOZ5rsUtsa +Envfs8Eq1hMhLAZskMdUiihB4MliK1WygoAsgDQR7APk/566W8RRQR+EkF3D +AFttHLSOA84TCfUcS4od1giT/fqijqyVrqZoC0pFllTH4dh0QwfPElJtuC43 +XGjkQeB6C23pA4pa3gFFraiiU1TsucvpxMtihjWz3UXiF0tOqw9DYCbSapsg +WUFkhjKuk6V4CPpSVXfMCl4OO8/Zw4ltvQRleZYKbU9tiixRKa0oQCHOlE+x +sEmaZXkcX00IweAa7oRL02ngmw1NGSKDGEB4imkAqGIUeiiGJigh2FUXxtqh +vGmhwiWIZW0DrfZNbBwIBcqay6VCXpO8iinZXOm5dOwrz01KQPwvrzpvr86u +OsOXv2LQHlN/EjqnIOC01L9ZHGwJj/tegCpcGeG04sMHvsBg+mFQZf8HcIXr +AxPCseqKgddZ+XvR+n577y3+X64v4mkCKRpSE1UBDyX0I/z2xuNqESkXoLof +SUpCx3qUOodRDtdzYUvURXuGOkuXqOZNjFFvlrwkWT28Xx47PzKzXPlT1Zrx +Fov3g0DG1MaCYQdUtna9GW+Mtxi1k4qvnCrCDfmSy9TwwdBqMU2RnkmIcBmd +OBs/JZu2kBDRiRFKEGlElUnVOcNzEmhB9UOVwQIBSGgE6z2K0+tYxfRp16Ic +rDrtwtkEHk91FLoqRUUjwY3AnC5BUwqL9VD1wxgdWOBE3PB0x8vO4OUIAt9u +v87uE+EKpz2u3CO8VUZlBrmCPnc4oFq1AllhAEX3IYKqdPv9y77CWAH7aXoW +x8aTy9Pu6PL1cHT5YvSq++qy/3NVjWIwaiYmlTLkGxiqSyUuV6vp0kVStEA6 +Jd2SzpwiFm3dfVpM41gew8JAsICu6c8rqp00gT4gKhv0/tmVo1TvosweUfEn +oeKjuJOuEmgFUjeN0tINEOTbKSrUUH/LhynJVbKQFV4Q8m9y+xXLLVX2M8Kb +lt2PpRXMmSKUlc/yM9EF6yhPIP/IFnNW6slGalKoJUuitOHikmqkFlFiWJ61 +rqRlWVWq1mktAUMdlErY5/jHuDLeKVMBk5ehvQjSRaBVxU4RhJJJHCL/Mhgm +FKlcSjuZDK81/RfeOb2xGa8jUdJ8HV3S67+Cir7oXZyOBp2fuvJQa1FJ2YcP +7F7+bimdICF/0+lf9C7O8sX8exljkiKVSTilegCHYGE9lwqgGeaRDjAOolno +MxItAJWIfcbncquYXZpffbApP3WJY6cJy0pLZm0DviSVEwiigiDyQ63/sTUq +Yg5ZiE/wbInaSvFMe7o+dZCGGEFgUBkunW8vvH6AZ2mCBw0HK38EYBy5SWlq +8a0EWaWMswpJBUaehIoqOpRUc9h2+RIOw/KI6fk2pxohRM08cIGFqOIEJ63m +4H/1bV3pp+0ZVUB02jHFbBY7UgzR2q8V/C2Q2SFygM4zHv8txHRZHZLGSoH6 +k3gMuv9QZXWmj9dqeKMMCFHLwoYcjARmRNzQU+xPsR+Dl/qUB6bGSPEeW77w +N46nJl5mwRpJYOOtFaX/qblHbPvTHGCuT02tFDU1hxdV5oMweGYF7/lcjpdG +JLRVE+8mIeJCkjWnmQ7jlC14N8J6VuW+3KDlrE9xRptCgLONWO6mkNZVKoUm +5p02MwpwtYrnumQhmD4LhJgDffX9DMWayF/sWu3XunSodSZg7d5YYqlWn32u +vmflK+Ws8RhyQMeQClTl7bk36XPzKgx06qqOl9SAN5j308tyFdUvISo70tPF +QlmyAtXNZPtK6fCqWG35Upe8t0XoFOHEXS5AofEveyJXKu3t7Rz+pNaUucFl +gkUKVYQtomu8Cp2c2N7rideuBU7eE+HMwD/Aiue2eHgcL4PTLRRdikytBA2U +ISsXtLloAE6G51Swk7ynomDzhs+RWJAZFZI9i7soClGdmQUlQ8hL4F1CzB1G +U13pKZVWbD2MV1aDjijk/bqlCUrO8UKmrgrhc6WccxiCeMlVgQNvb+P/8HEf +CUz7SLwiKQP/8+4r9kFFGK8vqNCZ+MkihUv85ovOsHNexxtUeJ8To4ekBJ13 +VpO40rISe6ksah+TKijDuovcs7gUk1v1WSwSCVg49lKnEqN0oJqUY7QbpEot +p1e01OFCupILapGcSuQc0aHzWz6eUFnozKM/+5vyqFjtk5dfCSsDpxzMwykd +/3mwfHETv+qGLlHV4gL5RwceLqW28u0qjzn2WNeXmYnlZNJmWY5nXiDdsHzT +kCr2C9X1+ESJDpq0A6eYTcflhjtX+jXljrWwJPhHRS19JKRr4/mVbFUEz7A5 +PpMIwGDeGuBVk5I28Rhr3oun78t2rsgkyoolylS2ZKkukY8pWFsMFOSzwHNF +cFArQ4eU1c2vbz5TYo43wmVkRUcCUhao7oqswIItfw+xS5O99O5QNupYrjPk +psm5shAn4sMAZM6/IrKcmvMgLTAvfCDwsFPY1/imVYmkBwU2daIshZUomaZK +gNccQMtEzJIzryMp0AkOXJgXWDQP9X7OQznPdvEaDaeYnLyMRItSWUd6iVbI +EgOpAHSgXZKaPsY847khbPMSloiMVEy8HPVP3/TBUF3hLf6LTv9n+H45+k95 +37qeRnIt+hs/RY2S2MhCEiB0dexsWUK2dnTbgOLJmczHh6Al9TECQoMl7Ywf ++LzFWbe6dVcD8iWe/W1nIqC7atVt1apV63rQqO+36FurAcSrpJrt48ZlEwvC +tw/wjWgZnh8A+s/AHekjwLvxH+g14CGH54cIC/Ymc8R/Ecf3RSzOt+BsgK7n +XBOJqtOiwGzNZm9CF73QFaiEUe15+6zpu59twbwLtPIFDBSRAa6CmJlAG/Km +i2RHfga4D/Ru+GbkQ1OPBSnCE1D+CeiNh/dxYgzXLsZD1GABWThF6duyc4Db +i689wpEIZDcBSm78TZARITN+YnVe3yAKkcOF98TptYc99X9OO/2E0XWNDqMQ +jslorqBZUrYVgjoIBwh/1dINxGb4D3FgMdzRqjvAS5JTwW0Y76zkiikXaqMp +VN5dujO+Ic9RNYnQM3qaiOKelcOJORcxqFRCoZSYdJK2HBfmCo5RajbnIGyN +gaXJ4PGkEw8aWWwek6zuIovT+jXWC7w+PG4Q//iy2wfeSiSbcL9XrOml51F2 +A5CezQIt+R3Tc81ekkNS6Y9DDJ/BeCkr5O3ZHIlzGziNNs5zm5W5RRE2wzi0 +tNni/5AUXYYT/Qfwlf9Y2lN/ugtrHpc1wSKttr6F6u2githVvDfgvsBRUc8d +0mzRH72Axv1oQDVW3/TaGB+ENkxlSz1/Tj2GEsnILwGbt1ypbtQ2t7Z3dvff +HhzWj5akFk0My7lgd5EI+m6UquwuCtTAfpV5T3FFM7En5+/MJaKop43QCNlX +wuJ/MA/+j6Ul57oR5Nu9IYpov2B5fYudYRZ/PkyBOEVX/I8OPHnxWUvn/GX7 +LOhFD78tWhFZfSpaMf2xaENUaL7Rp0jyvq3B55f7MnB38l2Vtmq+r9JWTckI +Vmf7MXCpQqWijqIrNvKsVtHIs1qzzkoAfY69qIAJ2IrWXG+lGuU6wo8cf6XB +1QSuKWGPpXH+q8VsTlyHJY4IsH4bdUY5rzh3SPgd7o9k1GE/J/Yq4JHt7IoT +qBi3kIidDb+dM5eFP6/8UnxwOqXIQD1YtIm62AC8lZnwtHm11e7Mq3HgZcqZ +rc6dB4tGsygoNs1G23wRgZgAFyTfpst+TghS8bCgRdndQefoKnvoktNMuWSd +JhIKPqSNQ3vIDkCBB10ES1BERpKw00syZmvD6bB/edIqGd+LVOPsXdN6e3J+ +8FddOFD2CoUBLm9II+rHEcoLU9VDbc2qr4yY6iUaBuoIp3xJLNspQA0iCpRQ +x+FOLKwC8EqTe7iO2lMIzZwzyXreUi9wBrPvaNI+02oKajgv6b6gvZozz1+r +5zmv2CyK3C12y+RusbulXaKMHJ6Vq+QSBPw3Lxubr+5li614xcRwce/Zymxw +5EMegKbgBMTe1XZq2LvaLiBfVTwfT0maihev6GHSvI8n3dvWsNgajrw9R2+1 +i4Lmlo/60+QWuVLLER90kAnGZ/SyxDKGzkfYJF2UaQyvdXYs4Hk7aGo7Tiaa +73X26rMVAzz3/qblLs0+2muzwbO6xmo/qeYQpRK4meiBuhtSYFD4jQw4d4Fr +s8QjQZRUeJkCfgcDmXXXlCq22MOkQ+Z8Q9hxQ7TR0wZ3XP+ug47ZhKFm2IqZ +xPvoBbSa9NkTYE1CSKEEMKEAUgwgmcT9vrXGBhS9G8LV4HIQP0QDtkQl5dr0 +ThIjFZd58rg6QKyU75Koi7bPOEzHcvge+jYZcvDjtWUqz5U+oOiO+BfqHYqj +ogHSsiMcOodMhnVjJSGa4w4AuLbuZhAkvovuOWbuQM6TZnwFjNlN4k9UInb+ +tN9FaOWIXK2oCHk0BnRI2PFGldFdz+0aM8wHw+lgsk/w3kobMCtvXqe6Ybhw +fZtBsvkJtZgIXiT5BfqxNvnUxkkUjtF5OuXHTr+4AB9wek3KIUfV5wTEvZEa +FPGVN7il1Lcw6WWqGCB7yWR6fU1b9BtZDmsqUMg70w1N4AJiPtIZsWKZTzix +zyapMP6m4CPeLXgBjsGnBh/E8B5AizDTPaBMrPEInRIB31CIHaOcUO/mjxFJ +xafkv5X4XhIuJOh/ByOK36FjDVfGcBfd4eCaTUEJNonGQw4uFukzbAeqqqJJ +9qg57rEqydLDAiORFkOrVtTvA8W9vrsZs8IMv1jjODpShfxS02+pqPgAyn23 +2dpvtNoHjeNWu1kn1ZF+Aw2ciUI/QhDGtUFPNMGU3uGRqMY9thcuPPTJDMEa +xj/0oQ6Dpa9rD8TRvKYdWjSGHdq8isuErauokTUY9XU0thYtb+m3fU+mSa+V +oM2yKj4nmA4EuKJTdBRUeqOyW9/ebIkBnIHqtVaoOzj3888/q+b788uTQ4Wm +KWq/0dj/uzo/Uo36ydHxSf3s/LC+mqjWuTpsnF+YlefVA4g4Z8ckYS82Tjm4 +yPFhCR7rUCPCAABFoZ5Qr+0BmdJGKPY9pM0UQDG9gUR0C6/rZ4d5C/4WBXCi +JEAzYzi/kaiv4vU70bop7Kc5R49R5TaaCoadPp50kgljqzah1jT29BGn+bTT +i3AUdXKvsTZxzutWdDdqRH0Zlmc2B11s3g7v1d0j0OFrtKoW+8KAv9TFu4vG ++YHYvEjvUIiKYXUQZVP9E+ViPp3zbyIhHuarLi9M1nI2O4l5D+tvL99VSNdB +KQqQUw4a6CHr/KfkHwNr//XEjS5E43/rPl98ozJDb5x6F9mwIX/sOXtT/IS/ +/ihXmmPIiAOEYaBk0FuVUrWqVrbgbiOXhgLfPYlhC2xjjJlQwKBDeKGjj69h +06X+VzDqAuFrWHUB8eXMugB4ArvONXTFr2PZBcgXM+1S32fb+eE6fS7Guq8y +ri3IvFPp0Q1w4DhiFzxsglV6HeKn4XFgqykUDGPwLURJROvtzV28DO9sb5Q2 +ttNBN7LU3pMVLUTsnyBdYlqfT5GfRmzzDo3/FRSYZCBPIsCai0MVYzboBC4i +e3bR5UQZ2xjcbp2rZNifolsWgxhEKODFnDIo9wDShiQHmJJ7ZMxh+5K7J9Mb +2ou4N3NuAixpnXsQmFgihf0JVWkfYMQZfLLuCWh1YMAqyYQrW9ulyvZWBu09 +nHX6493J8gpl7mQ5Nvl8x8mx87cMSnxdpJJhK3UyfvBNPs6GYfaHCBnzQB4H +NGfHPsgmINxxrBYuMFAChRvf7/eLIg1to2j0tN56f35I8RNTmuWCz/nlzWxu +qf/xU5vifL/p3GbFHSH6nC3l2rvOcCdh6S8FGQyLf1+F1mPOLd6hO5xrYKbu +wJOQJatvWMKuA1e1j8/cgFhpG5CANAiFA2zXiSEsTHYkAruU6h4JFZgsxjck +8RDJh7jlxUnGreoKL2ES1J9GqFOoran30QtKqkCp68npQKD2MLI2ohcwB3Ff +0XJc6VgKWlRLtnQ6J5UGqxUEQenKoYBtcTP1ARmyp5egGd/F/c64/1hS/Wii +zs90YAkeK9l3EPlGew5sz/RM62OG7kht8zD3jPnt4aAt2daFf3JuW1DqEzYB +jHA36q/34ojtNdErRQ4MCsOHLU9HDPn9+ckhLHwLdujlRauZHhF6n89EKc9Q +szMCHBiN2cNY3IFFUEtSO21pZMZlcPC1r6LwO3FIVEPi0TtgVJG4ZrqmI8eO +Vw1YXbK4S8jF5Ioy/hHLSjrTkhixwt2/i0I2VL8TL66YEQdmFqZrOF5bEzk3 +SSjhTBTkb2MwHLQ7spMuWd2kcyga62PEWjW8InW4+kVd7JfU9nple313R/3K +415nYQ8M5QoY20fuv3Hkv4qQdadTnYv3h9oPx71bn7eOj/6uGyY7oC7eWQSn ++sN77dijJPiismKmiWNsfBVxrJdYbwWOZ1KivnghTn4yC2dn5Awjazw6/RL5 +CsXx78PWHnWS5B7v+2zKRPJMDlXQQ3uo5LbTG97jNQZ+3GDUoe/STe7VhfSF +bOlSqH6CUYZR0jniw4O2KeVtAATTcUTYxMrRNdgWsK6GaZ/KwUj74xSZupuI +sccp8+7ywJk/iV1plJUctieVMFCnEbEIfN0BcscXNREjxz3XORWmbYpWZ9Rr +bSWa9mqm8zQhB1RtaAmHqpymeUcpi7/MkepM6XvE4JjMkZnKCemdjKd94y5r +5zJXSG97lDLgY9O9wELSHTRRHweAWnyODIZpQZ45r64e1Z10QyB4trtNWkMy +JqWEK0xgenvq8uJwv1Vn5gWP6jK+Jt01RdRgWPii8kLKlvgnh1dCfBJMZuKM +76oo/gecH3RGgPcTtQpragFVXyA30JSXdI9LIqAaDBVuCOPpYCAH2UBpsgBF +uH9CCm0xfafAOz70AvEIC8NVUE2mI+gSRfNCf4ZVEqWIhSHDgWmTdjFzB+1M +tu7Wb8prBUyKMsB8ODjhqa77CjvGImRGiiJhhUufZwMHe4P8Yux6OFqVDlq0 +3yMrkZ4geJ8I2hfyFjbrtVswUt3ZHq622F08mFXOt1h2cMqayFoPAL4akuMm +nHD65BMyDpdHjE0oviDX5tAi5OzEiV4f3HRi6k/iIKLKQ76KZjgd5fmfXLEp +vtxGh4PuOKaYMRjgazgdd9kVo4OHsLtvUH5GUaAQt4BqDoGUSsgluemiUfcY +mQNouje8W+OMTyJz29P8Gc2RaQsj0pCjAvY+JVwqRjclNq9FGwGUIDCMEeDi +8iveBhoeeaikngkgzptiW1xTH4SK3qO7CSkBHSDahYedHZi6obZPoEGlmNhJ +9q8VQHpzoYe7H48SpptKT5E20iIj/zoy+4MOC+H/6FquD5D6OXKhbRadJEUJ +tU+nCJ5GgjbpuO8IDw0suDZ+w3471Q3g5sVx4OkN+c96j9DHIPWIzd1SD8eB +Z1mONtvkmTZKC7w76Ex4UrKv8Jg3p61MIBuqpA9/mhsi5Bkus0RMcD4DLG5W +Aoez/eQzuHKAyvW23rw8rafZb1djpLQwxb2V5ghlqmU21NusbpSqZW02JLbv +JLLk4ZIIdl8Es5Sslyh4/eyQfHCEBAzQw0hFD7CFYwx7zjwIsW8aBkui7gBf +Ey9knETh67hhqXpayzdC284h7QoCklEZHLBSv7i8VjgmZhH14Zhe9x4r44br +6Lr3nfGAVihI00pyqerAWO79iI4ixkZTAQmaxfJ8WT4Ty1gk08aMii3XPDuq +1C05bb8oo9mD+yjOZRePRwtmH+HocAGAK8Q8aDMx306Oy6RxQbxCCxmzSXmu +PR/oB4XVLhjGTISHsi53cQ/vMRgvIGCLh3JI3CLDaw2CboUSG59vTz2KOkAr +kQzZrQ8RgC+6U1T73VGIqYELQsrTfCtVx/vrlHjE+4hJJq6+rM4SoKig+s4G +JweoVEsVrUyaO4HedjBTIsigD13jJal96Mgn7WbI6LWEa8+X+iVdM9EpR0sy +bn0ZyQiBAd9uhsYvkzn1gkM2noJ3ATnUE/DI4IX6PeEFre3GJsuWt3bdtUXI +Q8oRl3FzZWNRghykA7o+Tj9aFEwl8SCQkuCuVwvM/tfs1QNm4xbYrSt2VSSW +JLvpImm9BipNbAIjKAX8ozIY0IPYFuIDv27mVp42cxpvlT9zsG33Ft6goVnj +dCBlCkFe2d3cKW1KOqIcgNAg6W+0oekMES8Z+XrC85wys0Tni4h2n32VpNYd +pRmmL6+VOxL+Febf2cmhvcsKYznuzUWUiJ4AcWjvdAQlcMfmn9eCSSIyFBDM +CwCQJdk/S2tZKwELgkg+quhvBhwFJk4EEOIgWiJlw7n7ERDFYnmaBM90BkZ7 +Owd3rASSitzQ7e8m5ktcNi5e/uoQBoYXprTQymidIZngxcyC6WnN7hIvTiOy +syUhtXgpJl7OhA1wZtRnf9CYPoZ7EB60ivq/ZI7mloMEAmDBdUyEd5QwyAMh +JQJECEoOOZm9VnafB9ZG77ZbQz2JMnKcbGXPccZ5VmNQGt6OfzE+5iDRDEwY +PX2Um+t0aJZUlxQTcjOYN1nOzISJ7LMVs5+s5EQ7oGkGlEhwJpTe2Xkb4xRj +yKv/Omk7cYu1S5p2SOOw23RXz5OW6Vh74dNt/kLp243Kud0wQVYmQdl2hVi9 +aqWybcyGHF8FMnbYSz20hDH9RntK5DhGMDeEcQk6qZvEkC/mojfJO6hU7vHO +Y9ne4bEA+7qd8ut4cfziFbceI7+1urqqVWvuQmQPV7rA7aWfujOQx8fkndK6 +Qy3ToXl9EIcRyUHDWSar1UqpVtODRHOJA7RibkR9kgixhcjqm4cBIGryS/yr +zB7KLXpDcczEH+hwmy1c0vHLTXpBHU2tQBHnkDCjZgrpccb+1RDljOnLS7YO +06YxBfsTTVGyxZeV2Mi8i0jYWOQKIlwIG8xyERgMQNMh74Ju6X7BkrKdseLw +OQNO2RGagYfU/k+djuB8zJyOmVYFodFpA4OfcgwMnhkH5hnWj4zDhxRi5orF +h0Z4KeK8kIrlmfjq4rvB8L6kkBY/Mq2+0vJPOp0f0eCOQjbbPGdybn3mo19b +dXPcQYW23E20694/OSFT7os6vjuhnBhNrjpnYX3zpG+6rr/bZfVMmb7Vqn6f +RT3ah1+Hq63z1bf1VYpEk15h9KVTc1eYs4Yt4NL9+8qV/DAnV/LGtu/SvbGt +HhbKlvwgeY43HJfujb3yxl7FyT8J0Oe5dOemS95y0yVX+SCTo/pJSY6lpSc5 +bn9JXkvnDWfhFqft6vbmJjkIb29uids2oBJFwZHgOFoFLjl4TTwYI8CJMSLX +TYl0R9poIa8U8/Z+VBhTUxVMeELMUMmMYjZiId2KL1CjsoY5JbWXqJZz8/Wb +B7ezRQ6o8Gn8Y3VQRgullHM2m5gzB6boMnEQcIFq6rBoQAad49fbnQfv6wd/ +vTg/Pmu1m+8vW4fnH86WOcNvNmZQdkwocfNiZqiCFzCjZ/zNYlIz/enn9T/9 +/Ephas3gCxPIDS3nxDk61apJQZB5zo4qJZrUjU2Wr2xsViqaOQ0ZiyIe2Zmz +CxoIuBZYUTaeZYXVxXDY1xDDNsvcL/aFhs9NvdiMVRT6UY+ffAUuyL5g2P0Z +Bsy6H99FIh0KJ9BBkzRba2oPTFQz0daqYIwNHT6BJXTtT3F0n6wBtfxxNDmv +R/kpQ/2MoSozlDRxzmuhUKlRcjYirECca1t71R2bNzRDnXPhzCPQmyYpIZM4 +/HfUOD9FUyI6uDnUGVyx95vqBJChL3EbcTdo+zD+Bevu3nGI4R7FFPCwVlJ3 +cO9Q6LteUjdjEq1icjbkCnjr8xGv/nZc/5AJmpxA489WsGvN+kkdrUNNH71y +upeZbqAISvzmgXqkmkoislzERhRPgGnFn4/kdnjfht1hanB7+8Hk1ibpcYdc +Y34gZ5HuST5TUd71mYryrtK9zyBuCmhhxwsRUwVU27L8BADOYGwaQABTtx1M +3dglJxH8qAoNy5cHpaXWX+9nrdLmejZvl1Z7oawKGd+JG59fEpux7sec7pmc +XU4asDMUWWCqdtSHoaFu63aMJljGREWndiNp5eCRE3M96kx1/5xGyUQcQlMW +b98mdZXvgJA2YnQMufFwEaM/eokBzDEo1/GJtY3WVu1+cjHOPpdKzMiyHDsx +S8tZUdhXjkzROouVgyzzrK2N0tDfxc7mjsy4LaQ29saukr6v5u1rfl+obNld +Wd7cg/82t517wox9LQAC23rH2dY1trjAD62pFOEZMRXRmFnP6Z12kPLintDW +G3PCT2cLShYli0GBwANeltpZG24tB+ED5rAp5McZ4PBlHMOgLSGHf/tNkZVu +4F12Z2S2AZASBLzOhr6sfTDGYdn9YYIlzZssZ4p0S2OdwziwCfrx1eif61fR +6nWSTKZXyY/cB9m+5G6F7bK3E7bLyhtCejtkIRfgnmxOunKFgqFtmh2xnc2d +GwAxb08wu44fYoTkJiG3luxKAo3YWBq+3TxKaCrJxB5BubluAUZmF/wnJZFE +k2i0/U2fOlLLbxCdSfqftKFSWmzk7CLHGj+1Z66T7sPEjd04fzek+pC3EYw1 +GM6g1Ba/61kTGNgXvzjuCL+yniWwQQAgb9PO3drjj9sbXjdytkV1rVZzTwj6 +raTn6S3hASwA0TaoXC0DHu/VqrIbGGp6O/jVszths+oyfaTlWdmwyp7zxmG9 +oTCx1QX+rTfw82/1xsn+RVO+/F2dfzirN+giegF34uP9E3Wx32x+gLoK41xC +lQtUp5211MXJ/gEqIy/Om8eUTnm1cNGoHxw3MVcrfGvWG3+rG6u8i8bxKQbH +BrScWUqy3Zri0I/G8XkDH/zt+KT+rt5UaJ5dP7xsYN/ka516DHcTlHPCc2gB +5STweVRv1M8OoFajfnx2WP9Z5KB/q8NI4M3+aR0+LuBSs//2hL7CqOo8gdtl +EsHRZ9UozAqFweqb4Yi5rdfqjxuv5PEf/4hymzO8q71cHshTktYWfgvms21S +WgkqoOOZ+mYddxP1EoVBGM8H4RZTb0USTT36GFNeN62WPG15pgRchq0JsMcr +wR6vuD1OJyX+zr1N6Yq+tNfZvMnfud+6wa/ouXLnGzCrnbYeg36rL+o3RQio +7ZBKdHuzvGXVvr/JbtY/eE/rXzwUH3UP7Uvas+Yn7E77XfboDKL+MXpEpu+H +Mj2ZruSz/7WUsgAu1s4Icgi8LYHxX+0loAL38r2aoyyoZZUFWRBzCH21xpqC +mlYVFP6FeZBjxIOlkiHPn0v8Zhx1aXD4ShNi+w6Pcn6Da/4ZDTTM8559cWhr +0PTyG8IL8ya+64wf6QWRcvt8OOan5w14FkAUnSU5HnXXkxhVdD8SV0K9yUWX +raqHLVtVZQaQRpUQ3EJ1F5jJT7jUG6qyu7dZcUVBADyNLGEgc/ClusuaJR1R +l2kQ3Q0pPD+s6bQ/WWbVLH5FiueqQo+tB5z2ukvLrT0PI2Vvpgzw1axl79/d +jDl59u9g1Z3OzBARVFIigoqS/uctugO2APeUw6gra769t1HZgwW0YoJK7qJ7 +QLJr7saH3tgoVXaBldkobVT9+NBOFnPnIaZ86lC+dPXU1Obwagwde2o4aa1d +XFhf6aVLV9mOoAtN6hXpKNfvojujrMy8HCUitae3LC5R+3DRv7t71LHXTNJA +ziykUwNig2Q/KWnw6ApEonc2CCCHOXGunngGbjPzNTkhICT+p3ZQFE/hiLJD +JOgH+IrFedo9d3Ad30zZBc7EeTYJkaAL2r2ees1ZJCmRGOq3OH3IXeeBVBlJ +GxojPcErhI8Vrx7VzbS71qXSMJGSwPwMTbLqZ61mEerqyEjLhWIWEtwmvTLL +PN8yVspW7LhLHg3HOMKidf09PqSO30WT22EPNRX4qrX/Tr3Ex5POjQl4j/8C +kYsI1PlhncEAB1XiVnvDweRDB31+zExDy6zFcyNxM73riDunTdFBBi6lbItM +KAUCehJhI+cDrDhvWH43KXaZohc82BJdhPi3RsPlVGhzbIaCVp0+Er4Um+9P +66ft86OjZr1FsM+vr2Fh/VGXxPp9E++Sle2dUmWT6AfJIigxGgNjUYT6F6vz +z84vCG+hk07aafENdLLikX1peGtRKAM2pMEQ3HpToOmp8vcOWQdk94LyXHlN +eromtVBcylZYMqp5rrbsZp1mda+byPk0umtGk2IWTkmV05D4CpEtuvpmRFcE +jtYLC/Jf02jKKQefB0vD3/dAa+CV2N+xeItFXxUWB2/sliobtEiut/GT9o1K +Gz8ttmEIAWDR5awP7F6/Yd0eQ7dA7QZk92YjhMLWnq18C6rw9eQA5W4onJB9 +p+zOe+U8x5b1c2gcX71v7b8tuOVbSHlfifiSNhr6UNrI5ohmzx0gHoLZdgDL +yDCMY3EAGzZWI0zrMrjRlhnmHwX5Ink6mTI4sNf6nPvxdP+vdaENRaEmq165 +EW8xt5xdrHklhZ6q/AzlLoAHnblAB73j6VnZ3DSmInqaTLw2XX/1jUTfdycN +bW4wVNr+z2296E224sXDvucc5Whhb6PKUDyORCyQ7W7FsANvKexJ8Tm3iX9l +nzpj4ecn8YBnMweC9uh39roHA78JjJU8GKNFIaDVimBQG25kZ63ikrO79tB1 +FdNqOUeKMRzklaBomitbFZ13hPLqSUQccWJWxSmmRyV968/HhxTFomOnWMLc +8jHW6SdDBkKGDiYi7oBtLLWbNErVydCfIgAoid+YOeHskDVm23Ahd4/vGTFM +8K65VUeZimwFZJ78oinHrxg5kq0nYYbf4VDolLdw+JsuL6KarfIuzeaG8TWg +iVYY+R15UszJih1Fm6AD4O76MdxlCOgpkTsiJCWfT5B/qZY5KiX9C0+I/hcY +s4xad+m14oyT7fO/8ohpJJs8kh3rNVFIzVVsJgn/YeZOmnn122uixG+PW+3z +s2Ishvmfqcd6b9jSr5X5zt0ezSqQCZ9ZqdTYlbeyXSlVMpEElXOl9YK6KbjX +yXMJlKFPa2ZaJCOqz/BTRB2M2J5V7diDLRhCbsbxluUyvdTHDkgE5NcN8S7i +2JAKUKf8ufBngCaAeTXyKJN9/yLhiwUSzTWEQFA+RBh6VpJOoaf1S/j7kqtL +cpmNCgkoKhub26XKzo6n2W41LutpCxXqmY0ShD2TX8lCXUvnixXlLjlm+f5x +sePtRwquPKWg2qes90JDbJb5fJzQxJIj0bMhuGS37VEEAbhZAIDRkCNBOSAp +FQFnRKVOZVd1jbs04BQFjh0nUFsKjq2rwmXmlkUXGbx0ojDNwEbv6pCLm3Bo +tf/rsn5ZFyZIDinMTVPMHF1Ejlw2Cx5bTst/BfMUeoVMmPLZsHS9hwk3R4cB +SbKOewXO5n0i0E4MnS2kSC7dD+i+PJjeUTF0FKI60ADxerpLOKGFgr4OobTj +Gi7OShyR316+k6uGO61IYy+b9YYT9kr9BSe3G2FejzHj9548oV9W+4tWvmrJ +X8E9Z9Ve/4lNDeFTEuM5L/nEoFsKLsMf0CLpmiPCJBS91uvmn9WZDJ+e8Mql +pkqOMCnxi1v/V3PNStXxU+PaYBdXHaa2iiHsKRyCh5DLjmumOto/adatg6a7 +VNCrVJurb9JLaZEhVNpDlWfp/Lv2bTbUExR2MJpureYuD/dW4e/OAEOLHkPn +/nAO7AIwVHiNd+4GXJY4PmlQ0j867bphrt5FE4UOcJzXqCTevxIHmH3j1jkU +l+XzqO/soGI30+KDee50xTKo6bzwC4xMI6YHz95CAtcQXVHPvu4sFbxoNbKg +hBVekek6vhlgxMN4Et05gjzK1mlZW8ZIDieqOOOjpCAglKf9b7d3kegF5bv0 +0Jnm42YIUHCS29jkvH5IH+7HeOI8xG6jP3n0WVLa0vUrM2Sk3TNaD90hLLlZ +8gDynpxZmpnVMpd0KA1sygYbacLkvXkdLvFOLKTnvf8zz60L0yvuzcFAuNYs +1HCxHODPXFf8I95dsK8GkqdCknxzxCCzq6xMjEOuJRiwbMAB0aCSQMNFRik0 +ud5HD91oNNGxbSOCh3cnciSg0AQBJkFDat1iEoB7HVDPADAdEnd5XMI156Yr +1ZGnKqkxJhQiPNFsjumcccTXTy3gRG8NgWWy7yHNQd6aeboBRvMcEPdoSmAM +MBJhW8d9b7YPJIG6FEUlrrjoRc513wdQ+EbSF4eKZcUvK4UF5S+pgiGxSmZR +udoTpCwrTMHv884jSedOqdztQY5N4S9MCO+f6d7gSUqMULz5dEu832++b9cx +IJknfGVy5XTLOmmibN9XPdrDlusqSnmbyZSLjzOhCtA46vyofVo/PW/8fdlR +IGgXKUnMc0dh3HQwAiqS5jKEzbAYeHyN26gE28eTf+PWQo3Ro4N2jrDZGag4 +mTnT4BHWDFaazjk13MNwIdxRalGZGBXOkUfNlmXDWntd9EVceUA9yot/iWVI +gdLPNajZJ5UWeLmY5q+lOqXcat5NiscezG4hUeGp2EPfPNXugvxozVCW52aJ +zGJa8hKoKLLNX8q/psftvtFY7Eg/X6ZlnzS8eakxZuTGMOkpvOwYegxmEtwi +fnoMnkCbFIPjSBwStbXZL2QR+JTIHiC0jwJnAofvcc8QXjONWIfEzeaglC9o +DRb1EXYGO/9V5NPST3fXeyWIfrJLuP/CpEhh2pLi/MUwbjYdTV+//FOT5BPT +kbYZLmSvXQVxODHM4152svyL+GfnKhXu1SIX6G9+fab4RkupC7Enn3ITO/hq +YoVSM/meWOU73DG74/iKzL9Fdhgph3ZgbKbottO/Zm+oUBaLrByL1PzDAZEp +sm/BKI3TEe8PbLZNDr+4NyTFZadn20x85w1vFIsou8UufQAcqxZ8qGRKJh28 +kYGKF2NSfqpY/dnXxsCjlRVRtMbXRQq/okmaCI75ZUFAilwhpRakei5nZSVV +z913QiM1e0bMUczRXUJSUkFw6Ji0rjuTymhHwoJxtCqzZnbGZ0WRF9w6dlsd +YEA0jCthK9JimcqylfD/iGZoScCqXtJxY0IiJPHKNa1AvSyLVmsVDtK6VdHG +X6zOIruPFabYal1VyuxTvo6Ro6aDiQmRFVbWc7BZAQELuX9y/O6smNWBWzku +vhM5Luevr9Q47OLGdmmn6ol8CVNRn9Gm5PC/kIIl5cxEbt8O7sI2o0ecSTFX +QD8U4SvlBuA9OAL2GN2YooRTumHc6jFf2jsskNUhw9jTDiYltW/U9XRgd6TZ +QOku0iJdzxGJpgWVrnQzI1sMyy2fsTbWkbHO4ca4jifuckV22Rj8v6bEX08T +fv0QyVdG7BXi05xb/gKypCyVmCtZyhcrfRcGMcwdzuQKCwWhwPeIvcXrngdG +ro0Ghh9Hh8RX4TdPuL35Pkx1cuPFzuhAO8KELxk+Pd1dnolSgBd1O+g+/r69 +ezq+B1T3T5WMFj4XELHmDchlW9JUjRiXXqKjEol1ouG1mZBSzTQ1TaXC9sD6 +VDAYQCp4hcJqXTyZnG1dLNITmFik1bL6+ei5zGyEpgCANVx9PtaGVh2bzF11 +w8aYbn05Un5R4z73Zpp/sHHciJXIMtPaAfZwejfylalacOadHaJR5SO9Sir1 +lcp2tVyqcCw+tLpBARklN9fhQjV7xAGfDUKuSaR5wptV7ACRVu31aB/4Zllk +g8iPjJUVav5zT9h8I67UCatEyecykoBs2QOR6g7ztYVKbKlQBEMWDdqSRB8s +7MCpbFRR4ZI2y5ulDZjRnXK1VNl1zBX4IqJIWGNXz0txz+aiJoOG5D97Ydya +E9mmDgEw/Kdd+BlGzNbm4R6dXfUdZU01KZct6SF8f3KuQrnnGSNMirV1HX2W +2K+SJKKk4n4qDO5KrLXpw1ADzMKloqmVTIR1ytJD+aJQpkw1mLbhVavv5btP +7CXrrcn9EluOjyTY0wHGsehdKblvlaTbMps60Rv330t30BWbHqpA7KVJqOMa +vNq0MyZc6iBaM2YHDBh1P2ZjaUF3Agy0x8PLaIWPN7L5MSfxouh00kOyzFoh +ybXbVe4m2Q2QiZZP7M0ls2iTuap+MjDBsfQFEkkcHQF0QvmXS2KdnEczwwH6 +hI6uptmIl0QUnR5ieKuFe5iujAediMKuptclNQUisaMkbJdOj4upY/mIg8nu +diZFKrrk0Gs23dD3erSPX0qfyByEwFgdDR7dPUl7ziy4lReEdyhvCb3JhmMn +uWF2AWXHFPmWO9N4YwGb5bzrzHexx4iFUZpnl/FsnqFC4NbzbcwVsoBdo4Xf +pbnC7+PGxpY0952P0XR0xtq012y9ZuXEP8KS4duYMXzBnXGd0qsPB5jeiuXj +bAowvM7xNZIAzwF/I+JW81z+vsoywCUovmVxyiggVbA//B2YBCxiD/CFxgDX +8QNfo6JBNO707RVL1OpGLZgZNFwXsm061wU8V0jOWiE562vlUQqSs1I5kUZm +huGKXc1gC4ZdzRZCo14qIhALXGSse4yFVt1O28qvvBoS626B8t5yeg1hl9Xz +5yoD0R2LM7FOidevzUi8Hp12ko/quWOlfHREZsorUlYyp9Cy4m2XztZowIHF +nLu3KbXu9OInj6A9f+6271FwzYDBT+ysHiHmfsMOmo6nCCSKtGXUn604uZDB +qtUQVr1yy+pNM6OkLEvORsVlCe7QZa/2onv0Mx+5PK+Meqn0Soa6d7p002cP +zY4khjZoI1zVcOCmSOKwNjrFEgqGr4CF7/z3I7HMlAPnv6PxkBMrk9TZy6OU +nWDt9JWeTvN8HS2EHqyKiO3tS9wWBZBG/aklmcBWUH5XnWzyCzd+YA+9fp3Z +PnrnhEpn95oZk9Fd5JL6PcUxvXo+zZ93lOxxblCY+9Sh4hHZhlUb56mMXSWx +Q3nT2t9FtcRhFbHXqfH8Thk9ttOjr9AwB3jZHD3z1ymZ/00aZl/IFjghDSFP +U4UP0YtPkmHNxF4nJIB+CfbBfr/pjK9gX612h/0+0ACXKlDnmDT4230hPPV4 +Gr3/7JrNWi84BNGIDUYGPBjlv1y21MTlG8PosDAqWIutomH5lrMWW4IMyiKA +vRl5RGbO+qcRAOgse4rQFqGx0aZAF0qNBC4WOATGxLZ3D0Dui94MH+hN2H+K +t6lvqvBd7BRmWB24iDPD5oCkBHPjadwjtN9PRA3pTn5MjVTUzV1lRjA7poaU +mhNVIxtbLQfK7LAalQqr0ytGmw6nNoXl75KFZ8JWt3B/xEjlkiJYrdDTLgfC +V/q+qfQVP0El+tnlaRvrtN9eHh3VG02oVDEqeRMRw23F3ls1nJUVVrlDjYto +fNsZJdbC+Dq6V3dD8bNHYeLVI4XGXOUwDj2MOT3tR8lfJLyDVsZr2DMjuGDi +HPrze8A3pzNPiGwpvc/DNQcoRnhywzfPDWoZgjEHzza3KNQ4flR2PeOIQXR/ +1SfXRj/VoI21ii2gS9zhkAyOiD2lUORsc56JCukFX86J34ow/eiTOloxMz6J +iUKprCRsVhxKExudj0cnZXc6GKXWVdkUXtiZw+GF135xGYfcQlvNrnhB+E1E +lMUA01LCK4pKkxuMctIdjtYxOkw8efyRCO33IxeXqxUfmeG3sr1PI7QPNBSg +1cafQshpZE7VD+DxpheGiEJU4EdlxwZULNQHbg4eTni5rOMqOklz6aeXfi0b +OXBPcycci1qLrdyEaMnkbuLkA3LaWMlpIxPlz7RCaYG+TSNeitdCKMcuz8ws +yGpm9/f0lF4CfgVT32WnXZJ7lzGfS6VaqTrJveEf8IPADi1RAg03uOXSoquX +HrQADMTLXFp0tDrLnt9FSZu86GLkYZUHzYTDWxhsPiIJ4EwAy8BMzlvkABHj +6Fad3mQdDdiR9vw4QpbtS35SkC0/K8iWMt1PU7Is1FA0PRuAHUCniVkIxGyC +Vq1hmAP6S3tiEvfW4EyN7+Dm2bkbwfdPcHuMJ/wFdYH8rR8NOvgN9WXDAXx7 +oIr/QC4wggNy/BF+3XW68Be4sUmb/j8ZjtzfownVxDrjuA2zd3MD4OAJph/5 +bzhbMTij/j3sdvoRfAd2765DGTio6mqhk3TjGL7/czqcRFQYBU2o0Maq0QDd +Y9YwiehiBTN5RaAuIGw//ggv9/izSx9t6Ef3Fo6kYAoQuxQZgN/6CF64WcbE +s8UrIIqu96JP64Npv1+oUFaayi5wl+XyHv0nmJSPh1mg8zCyXCoDnS5VynS+ +Ajv4dXkd3BQP2vQhMFKKaN6MJqvMluIu1jYR5G6ISXUyxhRu1DsCTP98dZQ1 +uDg+rJ+1jo+ODyiLHbf4x/dRB+7gf/w22TlSY113YxGOhskEE9BSiEL3BQ6z +M4rDoQtvo84ok4ZN5xuCaZw8jqL5QQ9X0kEKr6ZxH7aw7gzFKPwANIMDQ1BY +FrImSK0TDQmbREEEG30w+67Zl5+h0P543HlUL28oB2MHfxhzu+l4fNx7QHGD +bq1t04uvh3FDraIQsTft4qWTsIAMRvDCioki8GoccmaQ+afsFc9WMrmKLt61 +jy7PiCto7zfeNeUacgRrcQBYhjnmUDj+EhenO8EuF7weq5d3jzxRrxYZvohq +mo2j9nGzfXTcaLYO9k9Oiss28+UUbimHUdItTKYjtAghfuCUvAR1b4b9Xpe/ +WoWtvY9rCyIpQgvYHQ+TZLXrmq+j/ppljDI24BmwX6ZT7eOz41YxI2VOYNq7 +t7gV2XXRtOO68mGbd1NALRiM6ZEAwF64EnE7GrRicwfapKZaw6L0cPUNwWwj +hDa33obHjtoa8RmWn2eOeiFxZyc4rdpZCwUfqMa57fTUVTRBAxY6QgIprwjR +4oHKJBETULqp1+IW3IrglomfehmLVYmEIw60+jmG5qujcL4oIEqquD+ZjM+m +d1fReFmh1wcc5UtGRAoE7efjw3N0ZFutkDPbl4CF3izdpMC26j+3gnAd5Fh9 +k/SHFL5Xt/QumjThkW4ngycHIuTWWjG8EyBZQWMm5BxiUouRvRHnLeXHqAXT +mEaXavS6wDBfspBJNHHdqvXuQ0l1amMuqxEl0dPeI95rUQ2a0XGWGN4FRlTt +bG23Lbgx2U0N5WEmAte2E9hkRTGlNxWF8okeK7OzDcLbPaElFfDX36cX9Qbt +0ma9dXnBDc2cjOxQsYo/kuAIPeMZt7xIZlD7mh3hn5VTdPXNIGLZS2IIHVHk +QuFTpz+Nkl+qrIFHvhZtrIBC6EdwMI8I6Qq0h185dXUIaHjyDnPNCrVFAzKv +cd32L5lurqz8aolH82M8MiF3NUfB/lMUIcAcL4/RxBq3/ERNoVqO3h7Fgzi5 +1QoCXMR4MI3Sm+MIcJ1pEp9iLu0kdwsHxSVyAE+UGzOAnwgmSymaupJ6oV6Y +YvTImAPJfJd/TYfiNimeZDwmP7HUqGANzuh9JAQdT8hKEbE0HjiqHHXQnKBx +ahoiyhl0N3jsGFKtM2rjzqcHRY/arL6ZTLrtiSY47ANg2wHKpeeEhyjWbjrO +ONYzXfAAl3jqRdEKe6kBe6hx1j4DQqhLloTgOPvPKXl4flbXJZfz1CbMYnU7 +3dto/YcHnw90Jj/2vC/32yqrvNDzAaizJX9beXcUH8acq8lWhRIV4Ie4Axjc +E1dz2EhNOrEPEC7ihhZrpyXQpgKM/ZQNH5KURPoCMw0c3PWk6Glyk6x1u6jZ +NzTwt99UqNTYK7WoDJt5DSXs/RwBtvar2J/Uz5HvDI2HEyyhthIdXP+JdgW9 +1emIl1XKaqsPV5ztOQXnYjjGT1+nCN4/Gr1tT2aoA8spfWCZo4/n4LYFWahs +OkgJGLm1V605isA8zHYgBNB6x8unUN3hhApVEx5bR2bW16LDoXp3eaCD/OHg +MDJPTma9gMIFKqezfUHf2r14PHlcLNMXNq9jwC+U8m5ulxfJdCdziZoujL/S +6QP//ztAuFR/8klqzSepNeWOIgf1UsALTrZ4VETX9soblrDW8tAvDWUOEm5s +UZIf/MhBwWyq1ZlpViWgpToAlgsQpP/IbizA9veGyF1R4IBH0icqnKMIS7F1 +BnL9N9N+Z+xGxQwg9QUNzyPbJoOofpfGSqi7ahSVBjNJ2sE1fDSMB+sYbqd3 +JR8/BPeynchX3m34ursNZfptsC0LrrDr5Biq7dV298pVq7XbsCgWqBrAq12X +uJVrLOLmT0IsYvfJfeOmFw0+vSoQH37x7nC/tc/MnboZCi4kiBWToXPUv4Rj +6lM8Hg6Q7rDhgwGYTK+ApCW/ANP6bLXwr6Wb/vCqgxHhluCOjyF35GtXvmIC +bf25Xln6jMfr/FooeBPxWhiI0yM0BUuikfes2xnfYHyEPwAZFnOJYrt98Pd3 +H47P2u1l5Cr0Y3iyUV12UVJEeesi5yNjkdt/P1IGu5GLljseVu4o6bVGySAw +T/tSre7VyoYbLCBEjZQ5leegZZWQsipmNzr5iKMtbEtUaliSi8b5u0a92SwU +yg9Qf1ZpVuu16odUtjKz7P7b8waVxKLVZ6uwB+DLBgXW/dSJ+2SzqKOVU65Z +nFUhXhg+Khl1uuRbOeTkzSxyzm9QawS5xQ0S+84Cx7ZBHHKSc9320CLucTjl +iINk/0Mud+6xznftKFkTyx9oJHoYsaOY9jzU9lHSRMz72KSASdkuFXZmbADO +FfTDNwB3Y0Z691R2dyX9ztkC/Hb2FnCsKXJqz94DFbIJqugI63r2G6dtlKq0 +jxFPChXvRfP0XUNeVL0XtFz8YsPioA3DhS9qXo339f0L3UbZe/O21ajX9Su/ +fTIWlTfVGUjB+Hj3O8AL05Nc1Kj5xLG2o2zvc7DDFJiNILVcIukAmIMjZU7c +Ax9MKaOHSTQecEag/bvYkSWdwwyM415U5IQ9/Q4F+5fy9MwTPB3GPWbVfD8x +l5Qc9+ZBIBOUOQBWcgE4PmmL9YFG7RVdaAgrudWl/S9ufpHx508gtN6NelGS +AhD3Kul4XHGvuhCk87FEAV4Q4owdbPSX30Fbn9+Wq6LPL7X6RL18LqR520+U +8ZtbootnB2zbEROxLX1h1waavagL96hOKvbAH497fzQa6usBqnNbH84vgLrW +2+8dFsJ5tljGvUx+Pwvs3fFh8/j/1FUF54VYD3GOR5H7i4Si3kwwqO+QY2NK +9gSySkbfKxN+K6uEdh3+8RKoQ/ZjXQnWz97c2vHPC1P0K2Wk49AtmNGcLKgx +5we19NkBLnpqdYylOcbaTTQJBFtRaIBDl8oEQ1eMo04yHPz0FxMeA/1sP0bR +iNTYJrAFDyaxiRT4HpJWa9sozmnXW31PTs0OK0lwYiiWwE3c+0UWg1QtwZg5 +tMVTug2aJ9ixMbCHKALiwODIVIoxG+IeerNhQAupI3NIXdDT54UXvHrMqvwJ +BuJEMh0h42iV2/k6t/DQs5r5f4kxgtFM4Wh5hoy+qPwr2ShkKr9y8Rnj5J1f +Z8oUB8uFopsmakXjBzWCaaOgyDJCEmqKqAn79wK3r43ARzKN9NEhpSi/G2Wl +lugQfO3NK06B40gh6MaoAIo9muTWQb/TJ1ZpjdGSZZEab4FxagJWj3TVcBW/ +EpDJj/vmwGaNVDGDuzpexo03e6ImdEEAGVi0dqD5oqt4dIr6ELnO2fBkCFen +samb2wbisSmVQoCAjckMBbSurL19OLCPpecpS/XU+cRJVn8468zdyJet+klz +typK+p3DNPPb2d4WW5W8M1tqp8/rLXvYc55LDkIpV6pAAlvDeQez2z41hy3L +egedqwRNRoMvrS0pJaTlJIHkDFLW8jhtA7zfaJXMz+MzLfawz5jOoy6Wf4tA +wRYgkcYz9Zk3ghh3caNbJHHZqpXEbr/1lq+GfjP8sH526PwioJhxzL7ldlbS +T0r2kU5Bj30hw3TTGSWpu3bI9WrHSCWZRShQ0KUWTNplEnVNikGqzWnUInpo +YRYKVw78FTFmKOAGf2WmgvcmlTmkCHTQD31WhQqol+mnbEi/u4lm9Lu7JUBj +iYf2M3qGodTmnmQ1yIJFzHe4NjfALNzGN7eqpq7iScKMzg3VH+vQeBRwCHYr +sD7sy7KqzzpsgoUCjAEsBwu8plVA6VK1bE/KTG2RowUKyKpRiUqwhLQwrw0r +6yo/bOQDcovVyu6iCAOBMZ/QpITZahMGt7zDbnubpWpV73Rp4TQeMGuAlJqv +hwUTsMUHV1IPA/SlX5Y00bRAenm89VCTqN9Hjgm5LmKNTAznEsdMJBWaDcSk +VzXMFuluaKrCuhOkFG3YAw/4hQ02GJdTHCP5EMIf1D7TSQS9bUT9IyDzZzCc +VULD3ng4oig510NETSWJRETDrI1HC8IfpjsU4LRwOjW/oIrFzJTqqiVkcJHt +kh4Tr5W3rDRruKoqPXqOQMjLjKn9yhnpx+VgHN3glWTMGng0i0EdXNH/Sfoy +/FLiai87Y8mC6ALji4Oz50WwYA9yt3S+Z1Iub5HrZpRbI897yK2QGgWO+2Ka +3DaGMhX0tEhmtMvGwE5PhMTkz0IYjjwAYTmBYwWNirwfya9kupLLs2xUfTkw +/FZ2AGnGJQO3UKk5zEt5r7K1V7EOKQg8zb1kQQQ4GNdTtLq7SYpg+uSjGu7I +B43iUvP9+Qe1f3LCdpn6SoZqf4WKu6Jk+zk/PsSQIRvbFVVU4jrysS0Wikpd +vDtrXsDfSyhWqapr+t9EfVJl4MZqu2ppSbVRqtJOV13Vz5epRe4T2emK3QxL +CuyRRwYJwZ5tSM/8W+cT+5a2Und6t+L2zmrE81wXUrf4Jd5X2Z5Xy9u70nOK +Z9GOkzZiFnwtFAJ9h3uzSlRFVbbUUnVL970QqB6eXLiic9wMXQq6ypEg1Kgz +uf3LUs7GZClAst5JHgc/dl+mevIErbnue2ZLpkCGBPC7IdV5PoA5+5HSy5p0 +3sAljKIx4rgq4mHfGXSj/jKaS19hth80yomvH+cb3aC6zTsetN3EGQHQdDdV +hg6RVBH/lDG2GSk41PMkvhl0+uoWxt+PxiTnigdOv9EAt9g8fnfZbFSXs13E +CRO47xkEFj7bP2EXjtnIiObPvwtc5I7ko2LVR8Wqkp7nYiK/n4OI1XxE1PVn +4+FGtbSpVjbQANNhhMjKViIutZEo3vfaABS/3oyH01HW0SbDM2gDxvYlQbno +JMk9sELITbImKU4YNfNxLVDT4p0rAKEsLnnCj358Nfrn+lW0ep0kk+lV8iOx +JduXfM2yrz6s7ChvCGm0yULOYE7FNTCrZHWIIRCzkae2hchT2xLkQTcRiUpz +ck6Gp3SGMmniyM3qFwXriRkK9we98f9TfwasGkf/8SnurEXd0dr1+I36VcJ7 +uzjRH8rVajbqQDE5c3MQ5W29fdRsti7fNnPRhW5u6wAjiejrj0SXbF/y6cum +b5IIv5U3iDTCZGGjCM2ai1X2atuAM5bUbNYyGBOAEcAY19S7UqttkeIZP+Xy +VXB81d/W3x2flfxnLMBiY7IkAuJGKS77j366S6rJZmMZb30SMmUd4o28y3ta +8h8bWdhKFq4RM5TCoMz7jLzobvLXGDM9ZyUTqWIya5ucBae2qa06Cnglb3Vu +CgWsb+RZPnz1ERvheYtQlPAp4hlCYTKZrA1HxLZyiko8uGka1zlsA4WMJa8V +uhvyP5J/FUz5jEmx1lDqcwjbywxecw45TraBbelrIH/clvT7kR84yI9PsL2l +pOPpbejDmx2dansrswPT1WfvvurGNnOd22bvFbJ6wpLSOlROMgyIljYScAKa +PSXxO7UHOEQwYAtDY0koRVjKuANb+4I08+RahA6Ri8CX0Vxod9p5Lc0CrqwG +kGAf3EbwR+KyJk64vXT8bZ4gBJtZAf8VxycvKRvg0URkTM0BLfsmSudXqps7 +pcqGy+ZhT1gq/S6anIiwe5pQ9PzUTcFVS0ph7NZZ5y4qms5qVCGp55Hx87+2 +mUjWvSQ4TqoYMjd0DHBpZyZrqgmEywlrhtTIPfHzkmelGIOc5DKvwrlNVt2q +qfwiKcA5yUZSNywsBfjkgRG+xI9yEdrW38UQck5jIXOZQLEvtZfJgppHucRg +plr5bsErnGHpR3IbTWYfdB/2T7SbadYS5/sEn2DTHsTYBhpuvm9bobr3cJZx +T5pzfkJCjgzX/YRUGaG6C2fKCFXWSSjCqnE7HTnsvht07/fAVySz7Y1rvnIc ++PMkbG/swwtpx60XZy2rHU9Vn7M7t8rkv1kO2JIiAE661jy9GTd0rD3YPIAf +pHjgWAaKlK2D6Z1eb46J6VBStzBCHVCNJAt3Rp2JtmWZ0xmBndXQhEId0imS +HnMm8GD64uowCRSpEK0+AjWA9ByIUtHRxamXL9mYJtNu19MvBRA+HSnmx6F8 +uiczxLibKTnupnIGkEb9NFzP07O8sVfd3au6blCbGezPQAjg/5aD/9u7ZHmB +H7tanIsIxEGwuq44gyVrvg4kLE1DHiobUcnlgAysOUFwXnFQTOUojYCd0zHG +wt3jApP2FIXN4Q7mIhe7ff9wzJJu5CvtUjo77Refh1HydrZH/EaW2/Frz0Gl +Kl30q9qcJixTDTq5ZwhMHuXKd5HPULIDvsTXB70Fm/Rro7O+9eA3oT+KLuWl +LyVlXppgDrnoxQ6dPx6/dD+e4AFiuh7GMP06ILqtOMd1VnSbrj4bxypbYs6m +7dncRasP8CbKbrannAswR2uU8sidpVpKlclBzNmQRLScV4ofS9wm/uHZ0mKO +6JKRPAzvDzHVH/3sTUdNwIDBJA/aWXQvALPHKhzUk/VxhCHgSBKKTtT9dgKI +j2Gy//0oOrs/M8THKemxyo5F4+zsJgrVbboHMnks722W9zY2HCmywd15YLI4 +vO2znNvEcoqTmyNKxF8tTNs4nI4nt4oUVmicpNtQ2HKqyio+gxWNMMgV3DvQ +4I6/9+IEmIDuJP27jS6RUvxu1I+7sSly26HpTaZX/EBNB6Sixcvj/x3GA9W5 +gVHfkLW9ZzwA33vDO+2xrijeUaKuJuMogj4BznHaBv7K2jlFuc/Rw/PZyv/8 +MSiPk0lIPE6DGo3jT7AFKPgJP8E4HLkbMXoYQZ+j3roPb204nXwHQcrCTbti +lYUrrT5RyLIo4Hk7zAQMJZHhCoofoCdao0HGlk3z2MQrTCh0iBiYSEC4F/0+ +pRKQ5MDYweTZykGjvt+qq9b+25O6GnG/2vhOFVEYeD0cXkHv/rbfOHi/3yhW +MFMLHh3HZ816o6WOz1rnfq2/7Z9c1puq+KLT6bzAkhjoHV8EQkY/WyE9BxS6 +vDjEXniQmvWWbv61enF1dfVCfXhfBwj2IbYBtZv1kzr6C6ijxvmpBwRe6uLY +EyPAAWjPVooVDHJJziKBzqkXULHyZeChXx54PQfZUIhiXYW2TKahGzhoual0 +cWwP35rWuP1KsLFMqOpnK5lH33KQC/deoEDlMlZOvF6nIndbFJmPcb1ejzDu +C4eioD70qWr7lIcV1W8zYamhfjXo7AD0pAJv1Se/Mpz/5CnbLoqi7LbDif6K +bgLMxeZ5w2nlyZtiw5vrxbHo+vr667FIARRof8NfCvTMk3zN1524X3JTRdMQ +sNsUoEJSrwOpnqL9+MwJknxMe0qlUwaQq5+kEY0Hq8C20nHECp9nKxSPCqq9 +yzhCun3Qk01DIO4f+IU8UkIdOmycXwQOlHyG3RyPY8xp8x3Yg6dy7NkO5cde +8VXMO1vKDiLIqmdhFyrblgWolvdqO3s1y6vvbM3hKSycACvhBqGqVLc5JgV+ +MsOu4ughnqjAv9+UbID4do0vbfAF8BRtU0soLo3Go0l7NCq6j8f667LabyoC +TbsnRt+L+w4gNBbq3I3UWIiKU1394Q8OALgE4lYnBjVK8jo3WBskI+wetoeX +lrsOd7a7huJkeUFskAzCfU7A+Tma1EUTbq4XXRfjNbxjmkKo6KGRFItF3Sv1 +oP7z/PiMxHT9DmyrroJtWSx2sSqQyYe1GK2q+higczlVNOaisVs0ejCFT+pH +LVPDsuUDrjWQWmaM9BbryZwW6Q1anSC1Hr/Y21vC2/cSjOfsEKbcfRvbt3rO +2Uc7FyH6a1Ze1F9bQj8DidEEvxwiQg9GqKWH56iTpgeSd9LQclcAu6z6RZMH +aIg1LXT57cJnKwlogdDxJhrDe2pHYfTUktJNoXgByBYS9QAHlh1eZhC5Zw/1 +ONAnrCBxhmlGaYvmz+iTsXi8hhA9zMUHiLhjg7ikioxpLgV1sScRqYFg/83E +3fFa9InffAN0tL1Vf36jXki4V8A7fKSnKIko7UWSM0UdIUKdNSmIX5GjuRmO +H+nxLUq4ODh3Zw3mftwxvyTqM3791BmjpRbVGE7HXfp2Fw/anzp9+tp5wK9m +uQHsfRsjo+v+wZJ3ijQWBinP5ZfukX5pOiUPbL90BQnSzr+kd7o2dVB+SB/1 +L+mmi2S4idqIhp/iyWN2Bnu0TIgXsL8AR3tr8MWgEFVGPJI4h23YVsVkTX4J +RqFRBW3oUAU0dA7UwVhVjwlWmq7B9/wGdc8zELoc4rD9z2mESz2rbpvcSzMQ +qCa/MwurCYuCnhVlikKggV+OcJ8DGAdowv247fSG92pq6G4IQO8qPSuveS2E +Gi86l695AmkykVTTib5RofB/8LmpT3TAOSCh3ag9vEqGqMLMYIIusZb027we +7hMKjuY/6g77w7H/CPaz/2A6iCeZIu3uHU+4fq5n6uy8pYr1n4+braaZfSyD +25gphammq/DrPvUFJiPTPyA4tBMSlHGFWBoz/vGapqKGcemudW2r52cnfwfG +vdNT4xKFKW93cUd1dU+6yGz10cwjw7FMho8RcDczGofX0jx+69zIlyUdFg4O +nGKlimEY4WnS6XfGj4R8ncEAQ/9o0gRvXz1bLdbMDbpYq8hX9Uy35Z4Y5rxI +HwvmeHqmCueNw3pDvf17qGY++w6cdFqwBY++t4Qvp9Vc4V5O+a+S64VhzuPD +RaS3NVei92+W6T1FqudKF36UZG+m0G5O3W8qk5spc5spdZvby8Wa//eJz75c +JDZD3rXwWv0AOdZM0cui6/ONpU/fU5qUEvPMFPTMEPX8f0brErRBgQEA + +--182774146-1920606540-1080058235=:513267 +Content-Type: text/plain +Content-Disposition: inline +Content-Transfer-Encoding: 8bit +MIME-Version: 1.0 + + +---------------------------(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 + +--182774146-1920606540-1080058235=:513267-- + +From pgsql-hackers-owner+M51641@postgresql.org Tue Mar 23 11:32:25 2004 +Return-path: +Received: from postgresql.org (svr1.postgresql.org [200.46.204.71]) + by candle.pha.pa.us (8.11.6/8.11.6) with ESMTP id i2NIWId29116 + for ; Tue, 23 Mar 2004 13:32:24 -0500 (EST) +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 28F60D1EC42 + for ; Tue, 23 Mar 2004 18:28:57 +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 11478-09 + for ; + Tue, 23 Mar 2004 14:28:55 -0400 (AST) +Received: from alvh.no-ip.org (200.85.202.54.DSL.surnet.cl [200.85.202.54]) + by svr1.postgresql.org (Postfix) with ESMTP id 7D042D1EC0D + for ; Tue, 23 Mar 2004 14:28:54 -0400 (AST) +Received: by alvh.no-ip.org (Postfix, from userid 500) + id 8877D5759D; Tue, 23 Mar 2004 13:28:43 -0500 (EST) +Date: Tue, 23 Mar 2004 14:28:43 -0400 +From: Alvaro Herrera +To: Heikki Linnakangas +cc: pgsql-hackers@postgresql.org +Subject: Re: [HACKERS] Two-phase commit +Message-ID: <20040323182843.GF3863@dcc.uchile.cl> +References: <200402080138.i181cPl15259@candle.pha.pa.us> +MIME-Version: 1.0 +Content-Type: text/plain; charset=us-ascii +Content-Disposition: inline +In-Reply-To: +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 +X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on + candle.pha.pa.us +X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham + version=2.61 +Status: ORr + +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 tried it, but I see it conflicts big time with my +modifications in access/transam/xact.c for subtransactions support. + +I am currently writing a proposal for nested transactions which will go +to -hackers, and I will be posting some code to -patches shortly +thereafter which should give you an idea where I am heading. Maybe then +we can have the opinion from the devel community about both things, +whether they should be applied or not. + +-- +Alvaro Herrera () +"El miedo atento y previsor es la madre de la seguridad" (E. Burke) + +---------------------------(end of broadcast)--------------------------- +TIP 6: Have you searched our list archives? + + http://archives.postgresql.org + +From jtv@xs4all.nl Tue Jun 29 10:18:43 2004 +Return-path: +Received: from smtp-out3.xs4all.nl (smtp-out3.xs4all.nl [194.109.24.13]) + by candle.pha.pa.us (8.11.6/8.11.6) with ESMTP id i5TEIeC19886 + for ; Tue, 29 Jun 2004 10:18:42 -0400 (EDT) +Received: from xs1.xs4all.nl (xs1.xs4all.nl [194.109.21.2]) + by smtp-out3.xs4all.nl (8.12.10/8.12.10) with ESMTP id i5TEIcdQ066827; + Tue, 29 Jun 2004 16:18:38 +0200 (CEST) +Received: from xs1.xs4all.nl (jtv@localhost.xs4all.nl [127.0.0.1]) + by xs1.xs4all.nl (8.12.10/8.12.10) with ESMTP id i5TEIcfr057746; + Tue, 29 Jun 2004 16:18:38 +0200 (CEST) + (envelope-from jtv@xs4all.nl) +Received: (from jtv@localhost) + by xs1.xs4all.nl (8.12.10/8.12.9/Submit) id i5TEIcD1057745; + Tue, 29 Jun 2004 16:18:38 +0200 (CEST) + (envelope-from jtv) +Date: Tue, 29 Jun 2004 16:18:38 +0200 +From: "Jeroen T. Vermeulen" +To: pgadmin@pse-consulting.de, Bruce Momjian +Subject: Two-phase commit +Message-ID: <20040629141837.GL56428@xs4all.nl> +MIME-Version: 1.0 +Content-Type: text/plain; charset=us-ascii +Content-Disposition: inline +User-Agent: Mutt/1.4.1i +X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on + candle.pha.pa.us +X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham + version=2.61 +Status: ORr + +Hi Andreas, Bruce: + +I briefly discussed this with both of you separately. The 2-phase-commit +patch that's being worked on has the shortcoming that the "supercommit" +is assumed to come over the same connection as the regular database +session, i.e. the transaction manager (the middleware that manages the +two-phase transaction across multibple databases etc.) also has to serve +as a proxy for the regular database session. + +A "real" two-phase commit system has the two phases of the transaction +going over separate connections--one between application and database +server, one between middleware and database server. Andreas quite +sensibly asked me why; and the real answer only just popped back into +my head. + +I think the real reason is the same reason why we want 2PC in the first +place. Connections may be lost _just_ when the middleware is sending out +second-phase commits to the various resource managers. In that case, it +is absolutely essential that the transaction manager be able to reconnect +to the resource manager (in this case, postgres) and continue where it +left off. A regular session can't do that, and that's exactly where the +2nd phase is being implemented right now. + +The way the current patch does things is more like the Oracle model. +Oracle has a "prepare commit" command (which I think even makes more +sense for this approach than making things look like nested transactions). +However I'm told that Oracle builds on the assumption of a two-tier +system, and it doesn't work very well. If two-tier were good enough, then +I suspect you might as well use something like my robusttransaction class +which catches the special case of losing connection during commit, then +tries to reconnect and find out whether the commit went through or not. + +As I mentioned to Bruce at FOSDEM last year, what I'd really need to get +that right (and the same goes for 2pc) I needed to be able to query the +transaction log in some way, to find out what happened to a transaction. +I've always assumed, and still believe, that what I did here was just a +hack to make the worst case a bit less likely. It's not what I would call +a solution to the atomicity problem. + +On the other hand, of course, at least one traditional argument for 3-tier +setups doesn't apply to us: we don't need connection pooling on the +middleware just to keep the per-connection licensing cost down. :) + + +Jeroen + +From pgsql-hackers-owner+M59934=pgman=candle.pha.pa.us@postgresql.org Tue Oct 12 15:27:20 2004 +Return-path: +Received: from svr1.postgresql.org (svr1.postgresql.org [200.46.204.71]) + by candle.pha.pa.us (8.11.6/8.11.6) with ESMTP id i9CJRJp09792 + for ; Tue, 12 Oct 2004 15:27:19 -0400 (EDT) +Received: from localhost (unknown [200.46.204.144]) + by svr1.postgresql.org (Postfix) with ESMTP id E0D5B32AD90 + for ; Tue, 12 Oct 2004 20:27:15 +0100 (BST) +Received: from svr1.postgresql.org ([200.46.204.71]) + by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) + with ESMTP id 89028-10 for ; + Tue, 12 Oct 2004 19:27:14 +0000 (GMT) +Received: from postgresql.org (svr1.postgresql.org [200.46.204.71]) + by svr1.postgresql.org (Postfix) with ESMTP id 524D832AC81 + for ; Tue, 12 Oct 2004 20:27:15 +0100 (BST) +X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org +Received: from localhost (unknown [200.46.204.144]) + by svr1.postgresql.org (Postfix) with ESMTP id 7B81632B6BE + for ; Thu, 7 Oct 2004 12:18:35 +0100 (BST) +Received: from svr1.postgresql.org ([200.46.204.71]) + by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) + with ESMTP id 22385-04 + for ; + Thu, 7 Oct 2004 11:17:11 +0000 (GMT) +Received: from smtp-3.hut.fi (smtp-3.hut.fi [130.233.228.93]) + by svr1.postgresql.org (Postfix) with ESMTP id 50FBE32B722 + for ; Thu, 7 Oct 2004 12:16:45 +0100 (BST) +Received: from kosh.hut.fi (kosh.hut.fi [130.233.228.10]) + by smtp-3.hut.fi (8.12.10/8.12.10) with ESMTP id i97BFicq021410; + Thu, 7 Oct 2004 14:15:45 +0300 +Date: Thu, 7 Oct 2004 14:15:44 +0300 (EEST) +From: Heikki Linnakangas +X-X-Sender: hlinnaka@kosh.hut.fi +To: Tom Lane +cc: Heikki Linnakangas , pgsql-hackers@postgresql.org +Subject: Re: [HACKERS] Two-phase commit +In-Reply-To: <354.1097099170@sss.pgh.pa.us> +Message-ID: +References: + <200402080138.i181cPl15259@candle.pha.pa.us> + <354.1097099170@sss.pgh.pa.us> +MIME-Version: 1.0 +Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed +X-RAVMilter-Version: 8.4.3(snapshot 20030212) (smtp-3.hut.fi) +X-Virus-Scanned: by amavisd-new at hub.org +X-Mailing-List: pgsql-hackers +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +X-Virus-Scanned: by amavisd-new at hub.org +X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on + candle.pha.pa.us +X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham + version=2.61 +Status: OR + +On Wed, 6 Oct 2004, Tom Lane wrote: + +> Quite some time ago, Heikki Linnakangas 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 know, but it seems like it can be the basis for a +> workable feature. I do have a few comments to make. + +Great! + +> 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 phase. When it recovers, it will be aware that it had committed +> to commit, but it won't know which nodes were successfully committed. +> So it will need to resend the COMMIT commands. It would be bad for the +> nodes to simply say "yes boss" if they are told to COMMIT a gid they +> have no record of. So I think the gid's have to stick around after +> COMMIT PREPARED or ROLLBACK PREPARED, and there needs to be a fourth +> command (RELEASE PREPARED?) to actually remove the state data when the +> transaction monitor is satisfied that everything's done. RELEASE of +> an unknown gid is okay to be a no-op. + +Hmm. I don't see a problem with the "yes boss" approach. Some kind of a +warning is appropriate, of course, but I don't see a reason for an +additional step. After all, you would still fall back to the "yes boss" +approach on the RELEASE PREPARED command. + +The transaction monitor knows if the 1st phase succeeded or not, so if the +COMMIT PREPARED doesn't find the transaction anymore, the monitor knows +that it's previous commit/rollback succeeded. + +> 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). Plus the actual content of each entry is not fixed-size either. +> This is not very workable given our fixed-size shared memory mechanism. + +I fully agree, I'm very dissatisfied with that part. + +> The idea that occurs to me instead is to not use WAL or shared memory at +> all for keeping the prepared-transaction state info. Instead, suppose +> that we store the status information in a file named after the GID, +> "$PGDATA/pg_twophase/gid". We could write the file with a CRC similarly +> to what's done for pg_control. Once such a file is written and fsync'd, +> it's equally as reliable as a WAL record would be, so it seems safe +> enough to me to report the PREPARE as done. COMMIT, ROLLBACK, and the +> pg_prepared_xacts system view would look into the pg_twophase directory +> to find out all about active prepared transactions; RELEASE PREPARED +> would simply delete the appropriate file. (Note: commit or rollback +> would need to take the transaction XID from the GID file and then look +> in pg_clog to find out if the transaction were already committed. These +> operations do not change the pg_twophase file, but they do write a +> normal transaction-commit or -abort WAL record and update pg_clog.) + +That sounds like a clever idea! I thought about using a single file +myself, but the multi-file approach is much simpler. + +> I think this would offer better performance as well as being more +> scalable, because the implementation you have looks like it would have +> some contention for the shared GID hashtable. + +I guess the performance would depend a lot on how good/bad the filesystem +is at creating and deleting a lot of small files. + +> I would be inclined to require GIDs to be numbers (probably int8's) +> instead of strings, so that we don't have any problems with funny +> characters in the file names. That's negotiable though, as we could +> certainly uuencode the strings or something to avoid that trap. + +I'm afraid we have to support arbitrary strings. I think at least the Java +Transaction API requires that, I'm not sure though if that could be +worked around in the JDBC driver. + +> 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' with a zero pg_subtrans parent link +> to mean a prepared transaction. This would imply factoring prepared +> XIDs into GlobalXmin (so that pg_subtrans entries don't get recycled +> too soon) but we probably have to do that anyway. AFAICS, prepared +> but uncommitted XIDs have to be considered still InProgress, so if +> they are less than GlobalXmin we'd lose. + +Yes, they must be considered InProgress. The snapshot code needs to be +modified to handle an arbitrary number of in progress transactions. + + +I've been thinking if it would be useful to have the COMMIT +PREPARED/ROLLBACK PREPARED commands under transaction control themselves. +You could for example do "BEGIN; COMMIT PREPARED mygid; COMMIT PREPARED +mygid2; COMMIT;" to atomically commit two already-prepared transactions, +and even chain the 2PC transactions like "BEGIN; COMMIT PREPARED mygid; +PREPARE TRANSACTION mygid2". It seems feasible to implement, just postpone +the actual 2nd phase commit to the end of the commit of the enclosing +transaction. + +- Heikki + +---------------------------(end of broadcast)--------------------------- +TIP 7: don't forget to increase your free space map settings + +From pgsql-hackers-owner+M59924=pgman=candle.pha.pa.us@postgresql.org Tue Oct 12 15:25:43 2004 +Return-path: +Received: from svr1.postgresql.org (svr1.postgresql.org [200.46.204.71]) + by candle.pha.pa.us (8.11.6/8.11.6) with ESMTP id i9CJPfp08866 + for ; Tue, 12 Oct 2004 15:25:42 -0400 (EDT) +Received: from localhost (unknown [200.46.204.144]) + by svr1.postgresql.org (Postfix) with ESMTP id C0C3D32BB7C + for ; Tue, 12 Oct 2004 20:25:37 +0100 (BST) +Received: from svr1.postgresql.org ([200.46.204.71]) + by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) + with ESMTP id 86781-07 for ; + Tue, 12 Oct 2004 19:25:36 +0000 (GMT) +Received: from postgresql.org (svr1.postgresql.org [200.46.204.71]) + by svr1.postgresql.org (Postfix) with ESMTP id 2F57A32BB46 + for ; Tue, 12 Oct 2004 20:25:37 +0100 (BST) +X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org +Received: from localhost (unknown [200.46.204.144]) + by svr1.postgresql.org (Postfix) with ESMTP id B4BAD32A071 + for ; Sat, 9 Oct 2004 12:48:23 +0100 (BST) +Received: from svr1.postgresql.org ([200.46.204.71]) + by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) + with ESMTP id 38695-06 + for ; + Sat, 9 Oct 2004 11:48:09 +0000 (GMT) +Received: from smtp-3.hut.fi (smtp-3.hut.fi [130.233.228.93]) + by svr1.postgresql.org (Postfix) with ESMTP id A887832A4FE + for ; Sat, 9 Oct 2004 12:48:10 +0100 (BST) +Received: from kosh.hut.fi (kosh.hut.fi [130.233.228.10]) + by smtp-3.hut.fi (8.12.10/8.12.10) with ESMTP id i99Bm9UD031611 + for ; Sat, 9 Oct 2004 14:48:09 +0300 +Date: Sat, 9 Oct 2004 14:48:09 +0300 (EEST) +From: Heikki Linnakangas +X-X-Sender: hlinnaka@kosh.hut.fi +To: pgsql-hackers@postgresql.org +Subject: [HACKERS] Two-phase commit patch updated +In-Reply-To: <354.1097099170@sss.pgh.pa.us> +Message-ID: +References: + <200402080138.i181cPl15259@candle.pha.pa.us> + <354.1097099170@sss.pgh.pa.us> +MIME-Version: 1.0 +Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed +X-RAVMilter-Version: 8.4.3(snapshot 20030212) (smtp-3.hut.fi) +X-Virus-Scanned: by amavisd-new at hub.org +X-Mailing-List: pgsql-hackers +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +X-Virus-Scanned: by amavisd-new at hub.org +X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on + candle.pha.pa.us +X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham + version=2.61 +Status: OR + +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 with the unregister command + (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) + +From pgsql-hackers-owner+M60193=pgman=candle.pha.pa.us@postgresql.org Wed Oct 20 11:43:40 2004 +Return-path: +Received: from svr1.postgresql.org (svr1.postgresql.org [200.46.204.71]) + by candle.pha.pa.us (8.11.6/8.11.6) with ESMTP id i9KFhdf10906 + for ; Wed, 20 Oct 2004 11:43:40 -0400 (EDT) +Received: from localhost (unknown [200.46.204.144]) + by svr1.postgresql.org (Postfix) with ESMTP id 6358632A158 + for ; Wed, 20 Oct 2004 16:43:37 +0100 (BST) +Received: from svr1.postgresql.org ([200.46.204.71]) + by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) + with ESMTP id 60338-02 for ; + Wed, 20 Oct 2004 15:43:36 +0000 (GMT) +Received: from postgresql.org (svr1.postgresql.org [200.46.204.71]) + by svr1.postgresql.org (Postfix) with ESMTP id 01CF832A12A + for ; Wed, 20 Oct 2004 16:43:37 +0100 (BST) +X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org +Received: from localhost (unknown [200.46.204.144]) + by svr1.postgresql.org (Postfix) with ESMTP id 0A2B932B107 + for ; Wed, 20 Oct 2004 16:41:15 +0100 (BST) +Received: from svr1.postgresql.org ([200.46.204.71]) + by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) + with ESMTP id 74851-10 + for ; + Wed, 20 Oct 2004 15:41:08 +0000 (GMT) +Received: from mailsrvr2.bull.com (mailsrvr2.bull.com [192.90.162.8]) + by svr1.postgresql.org (Postfix) with ESMTP id 58BB532AF80 + for ; Wed, 20 Oct 2004 16:41:07 +0100 (BST) +Received: from us-phx1.az05.bull.com (us-phx1.az05.bull.com [141.112.40.1]) + by mailsrvr2.bull.com (8.13.1/8.13.1) with ESMTP id i9KFeskm013495 + for ; Wed, 20 Oct 2004 08:40:54 -0700 +To: pgsql-hackers@postgresql.org +Subject: [HACKERS] 2PC support +MIME-Version: 1.0 +X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 +Message-ID: +From: Michael.Giroux@objectweb.org +Date: Wed, 20 Oct 2004 08:40:53 -0700 +X-MIMETrack: Serialize by Router on US-PHX1/US/BULL(Release 6.5.1|January 21, 2004) at + 10/20/2004 08:40:54 AM, + Serialize complete at 10/20/2004 08:40:54 AM +Content-Type: text/plain; charset="US-ASCII" +X-BullServices-MailScanner-Information: Please contact the ISP for more information +X-BullServices-MailScanner: Not scanned: please contact your Internet E-Mail Service Provider for details +X-MailScanner-From: michael.giroux@objectweb.org +X-Virus-Scanned: by amavisd-new at hub.org +X-Mailing-List: pgsql-hackers +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +X-Virus-Scanned: by amavisd-new at hub.org +Status: OR + +Hi, +I've read a few of the recent posts about 2-phase-commit support. I +noticed some discussion related to persisting the state of in-doubt +transactions, and thought you might be able to take advantage of work that +has been going on in the area of transaction logs. + +I'm working on a project (howl.objectweb.org) to implement a journal +designed specifically to support transaction managers 2PC protocol. The +project was concieved during a meeting between ObjectWeb and Apache +Geronimo developers last year at ApacheCon 2003. The journal is currently +used by the Apache Geronimo TM, Codehaus ActiveMQ, and ObjectWeb JOTM +projects. + +Although the main objective is to support TM 2PC protocol, it could be +used as a database before-image journal as well. The code is BSD +licensed. More at http://howl.objectweb.org. + +Also, with respect to the requirements for the 2PC protocol, there is an +excellent discussion by Mike Spille. Mike wrote a series of articles +titled "XA Exposed". You can review the articles at +http://www.theserverside.com. Search for "xa exposed". + +If any of you will be at ApacheCon 2004 next month, I'm giving a paper on +the HOWL journal. I'll be happy to talk with you there. + +Michael Giroux, objectweb.org + +---------------------------(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+M63326=pgman=candle.pha.pa.us@postgresql.org Wed Jan 19 13:02:04 2005 +Return-path: +Received: from svr1.postgresql.org (svr1.postgresql.org [200.46.204.71]) + by candle.pha.pa.us (8.11.6/8.11.6) with ESMTP id j0JJ23w15071 + for ; Wed, 19 Jan 2005 14:02:03 -0500 (EST) +Received: from localhost (unknown [200.46.204.144]) + by svr1.postgresql.org (Postfix) with ESMTP id 86EA13A438A + for ; Wed, 19 Jan 2005 19:02:00 +0000 (GMT) +Received: from svr1.postgresql.org ([200.46.204.71]) + by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) + with ESMTP id 39979-07 for ; + Wed, 19 Jan 2005 19:01:58 +0000 (GMT) +Received: from postgresql.org (svr1.postgresql.org [200.46.204.71]) + by svr1.postgresql.org (Postfix) with ESMTP id DC7E53A4447 + for ; Wed, 19 Jan 2005 19:01:45 +0000 (GMT) +X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org +Received: from localhost (unknown [200.46.204.144]) + by svr1.postgresql.org (Postfix) with ESMTP id E30A83A43DE + for ; Wed, 19 Jan 2005 18:59:59 +0000 (GMT) +Received: from svr1.postgresql.org ([200.46.204.71]) + by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) + with ESMTP id 39733-06 + for ; + Wed, 19 Jan 2005 18:59:49 +0000 (GMT) +Received: from smtp-3.hut.fi (smtp-3.hut.fi [130.233.228.93]) + by svr1.postgresql.org (Postfix) with ESMTP id 83C883A42C9 + for ; Wed, 19 Jan 2005 18:59:48 +0000 (GMT) +Received: from localhost (putosiko.hut.fi [130.233.228.114]) + by smtp-3.hut.fi (8.12.10/8.12.10) with ESMTP id j0JIxkeL013491 + for ; Wed, 19 Jan 2005 20:59:46 +0200 +Received: from smtp-3.hut.fi ([130.233.228.93]) + by localhost (putosiko.hut.fi [130.233.228.114]) (amavisd-new, port 10024) + with LMTP id 17639-01-10 for ; + Wed, 19 Jan 2005 20:59:45 +0200 (EET) +Received: from kosh.hut.fi (kosh.hut.fi [130.233.228.10]) + by smtp-3.hut.fi (8.12.10/8.12.10) with ESMTP id j0JItvEJ011614 + for ; Wed, 19 Jan 2005 20:55:57 +0200 +Date: Wed, 19 Jan 2005 20:55:57 +0200 (EET) +From: Heikki Linnakangas +X-X-Sender: hlinnaka@kosh.hut.fi +To: pgsql-hackers@postgresql.org +Subject: [HACKERS] Two-phase commit for 8.1 +Message-ID: +MIME-Version: 1.0 +Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed +X-TKK-Virus-Scanned: by amavisd-new-2.1.2-hutcc at putosiko.hut.fi +X-Virus-Scanned: by amavisd-new at hub.org +X-Mailing-List: pgsql-hackers +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +X-Virus-Scanned: by amavisd-new at hub.org +X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on + candle.pha.pa.us +X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham + version=2.61 +Status: OR + +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 +requires an initdb (or pg_upgrade). + +Any comments on the implementation or the new commands? + +I would appreciate help testing the JDBC driver with an application server that +does XA recovery properly. + +- Heikki + +---------------------------(end of broadcast)--------------------------- +TIP 2: you can get off all lists at once with the unregister command + (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) + +From pgsql-hackers-owner+M63328=pgman=candle.pha.pa.us@postgresql.org Wed Jan 19 15:00:49 2005 +Return-path: +Received: from svr1.postgresql.org (svr1.postgresql.org [200.46.204.71]) + by candle.pha.pa.us (8.11.6/8.11.6) with ESMTP id j0JL0lw26408 + for ; Wed, 19 Jan 2005 16:00:47 -0500 (EST) +Received: from localhost (unknown [200.46.204.144]) + by svr1.postgresql.org (Postfix) with ESMTP id AA4F63A44F7 + for ; Wed, 19 Jan 2005 21:00:43 +0000 (GMT) +Received: from svr1.postgresql.org ([200.46.204.71]) + by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) + with ESMTP id 69508-07 for ; + Wed, 19 Jan 2005 21:00:41 +0000 (GMT) +Received: from postgresql.org (svr1.postgresql.org [200.46.204.71]) + by svr1.postgresql.org (Postfix) with ESMTP id 954C03A4493 + for ; Wed, 19 Jan 2005 21:00:42 +0000 (GMT) +X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org +Received: from localhost (unknown [200.46.204.144]) + by svr1.postgresql.org (Postfix) with ESMTP id AEE2A3A4447 + for ; Wed, 19 Jan 2005 20:59:06 +0000 (GMT) +Received: from svr1.postgresql.org ([200.46.204.71]) + by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) + with ESMTP id 69310-05 + for ; + Wed, 19 Jan 2005 20:58:55 +0000 (GMT) +Received: from hub.org (hub.org [200.46.204.220]) + by svr1.postgresql.org (Postfix) with ESMTP id BD0E03A43DA + for ; Wed, 19 Jan 2005 20:58:56 +0000 (GMT) +Received: from ganymede.hub.org (blk-224-186-245.eastlink.ca [24.224.186.245]) + by hub.org (Postfix) with ESMTP id 864D2129256; + Wed, 19 Jan 2005 16:58:54 -0400 (AST) +Received: by ganymede.hub.org (Postfix, from userid 1000) + id B19BA5E34A; Wed, 19 Jan 2005 16:58:55 -0400 (AST) +Received: from localhost (localhost [127.0.0.1]) + by ganymede.hub.org (Postfix) with ESMTP id AD3675DCBC; + Wed, 19 Jan 2005 16:58:55 -0400 (AST) +Date: Wed, 19 Jan 2005 16:58:55 -0400 (AST) +From: "Marc G. Fournier" +X-X-Sender: scrappy@ganymede.hub.org +To: Heikki Linnakangas +cc: pgsql-hackers@postgresql.org +Subject: Re: [HACKERS] Two-phase commit for 8.1 +In-Reply-To: +Message-ID: <20050119165747.U47533@ganymede.hub.org> +References: +MIME-Version: 1.0 +Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed +X-Virus-Scanned: by amavisd-new at hub.org +X-Mailing-List: pgsql-hackers +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +X-Virus-Scanned: by amavisd-new at hub.org +X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on + candle.pha.pa.us +X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham + version=2.61 +Status: OR + + +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 Linnakangas wrote: + +> 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 +> requires an initdb (or pg_upgrade). +> +> Any comments on the implementation or the new commands? +> +> I would appreciate help testing the JDBC driver with an application server +> that does XA recovery properly. +> +> - Heikki +> +> ---------------------------(end of broadcast)--------------------------- +> TIP 2: you can get off all lists at once with the unregister command +> (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) +> + +---- +Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) +Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664 + +---------------------------(end of broadcast)--------------------------- +TIP 5: Have you checked our extensive FAQ? + + http://www.postgresql.org/docs/faqs/FAQ.html + +From pgsql-hackers-owner+M63331=pgman=candle.pha.pa.us@postgresql.org Wed Jan 19 18:45:25 2005 +Return-path: +Received: from svr1.postgresql.org (svr1.postgresql.org [200.46.204.71]) + by candle.pha.pa.us (8.11.6/8.11.6) with ESMTP id j0K0jOw15340 + for ; Wed, 19 Jan 2005 19:45:24 -0500 (EST) +Received: from localhost (unknown [200.46.204.144]) + by svr1.postgresql.org (Postfix) with ESMTP id 40B203A45A5 + for ; Thu, 20 Jan 2005 00:45:20 +0000 (GMT) +Received: from svr1.postgresql.org ([200.46.204.71]) + by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) + with ESMTP id 91025-08 for ; + Thu, 20 Jan 2005 00:45:16 +0000 (GMT) +Received: from postgresql.org (svr1.postgresql.org [200.46.204.71]) + by svr1.postgresql.org (Postfix) with ESMTP id 46A8F3A459D + for ; Thu, 20 Jan 2005 00:45:19 +0000 (GMT) +X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org +Received: from localhost (unknown [200.46.204.144]) + by svr1.postgresql.org (Postfix) with ESMTP id 042FE3A4340; + Thu, 20 Jan 2005 00:42:14 +0000 (GMT) +Received: from svr1.postgresql.org ([200.46.204.71]) + by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) + with ESMTP id 91212-03; Thu, 20 Jan 2005 00:42:05 +0000 (GMT) +Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) + by svr1.postgresql.org (Postfix) with ESMTP id 493723A42C9; + Thu, 20 Jan 2005 00:42:08 +0000 (GMT) +Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) + by sss.pgh.pa.us (8.13.1/8.13.1) with ESMTP id j0K0g4GY001116; + Wed, 19 Jan 2005 19:42:04 -0500 (EST) +To: "Marc G. Fournier" +cc: Heikki Linnakangas , pgsql-hackers@postgresql.org +Subject: Re: [HACKERS] Two-phase commit for 8.1 +In-Reply-To: <20050119165747.U47533@ganymede.hub.org> +References: <20050119165747.U47533@ganymede.hub.org> +Comments: In-reply-to "Marc G. Fournier" + message dated "Wed, 19 Jan 2005 16:58:55 -0400" +Date: Wed, 19 Jan 2005 19:42:03 -0500 +Message-ID: <1115.1106181723@sss.pgh.pa.us> +From: Tom Lane +X-Virus-Scanned: by amavisd-new at hub.org +X-Mailing-List: pgsql-hackers +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +X-Virus-Scanned: by amavisd-new at hub.org +Status: OR + +"Marc G. Fournier" 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 helping Heikki finish it up, +but if we stick to the 2-month-dev-cycle idea I'm afraid there's no way +it'll be done in time. I thought that "some time" would probably amount +to a solid man-month or so, and there's no way I can spend half my time +on just one feature for this cycle. + +If Heikki wants this in for 8.1, the right thing to do is vote against +the short-dev-cycle idea. But we need a plausible answer about what to +do about ARC to make that credible... + + regards, tom lane + +---------------------------(end of broadcast)--------------------------- +TIP 6: Have you searched our list archives? + + http://archives.postgresql.org + +From pgsql-hackers-owner+M63432=pgman=candle.pha.pa.us@postgresql.org Sun Jan 23 05:41:58 2005 +Return-path: +Received: from svr1.postgresql.org (svr1.postgresql.org [200.46.204.71]) + by candle.pha.pa.us (8.11.6/8.11.6) with ESMTP id j0NBfvw06363 + for ; Sun, 23 Jan 2005 06:41:58 -0500 (EST) +Received: from localhost (unknown [200.46.204.144]) + by svr1.postgresql.org (Postfix) with ESMTP id D0CA53A3BE7 + for ; Sun, 23 Jan 2005 11:41:55 +0000 (GMT) +Received: from svr1.postgresql.org ([200.46.204.71]) + by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) + with ESMTP id 51743-08 for ; + Sun, 23 Jan 2005 11:41:52 +0000 (GMT) +Received: from postgresql.org (svr1.postgresql.org [200.46.204.71]) + by svr1.postgresql.org (Postfix) with ESMTP id E67533A51E4 + for ; Sun, 23 Jan 2005 11:41:10 +0000 (GMT) +X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org +Received: from localhost (unknown [200.46.204.144]) + by svr1.postgresql.org (Postfix) with ESMTP id CB87F3A525A + for ; Sun, 23 Jan 2005 11:39:49 +0000 (GMT) +Received: from svr1.postgresql.org ([200.46.204.71]) + by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) + with ESMTP id 51345-07 + for ; + Sun, 23 Jan 2005 11:39:32 +0000 (GMT) +Received: from smtp-3.hut.fi (smtp-3.hut.fi [130.233.228.93]) + by svr1.postgresql.org (Postfix) with ESMTP id 5F3223A1AA3 + for ; Sun, 23 Jan 2005 11:38:50 +0000 (GMT) +Received: from localhost (katosiko.hut.fi [130.233.228.115]) + by smtp-3.hut.fi (8.12.10/8.12.10) with ESMTP id j0NBcmeL011515; + Sun, 23 Jan 2005 13:38:48 +0200 +Received: from smtp-3.hut.fi ([130.233.228.93]) + by localhost (katosiko.hut.fi [130.233.228.115]) (amavisd-new, port 10024) + with LMTP id 04384-02-2; Sun, 23 Jan 2005 13:38:47 +0200 (EET) +Received: from kosh.hut.fi (kosh.hut.fi [130.233.228.10]) + by smtp-3.hut.fi (8.12.10/8.12.10) with ESMTP id j0NBbUEJ011361; + Sun, 23 Jan 2005 13:37:30 +0200 +Date: Sun, 23 Jan 2005 13:37:30 +0200 (EET) +From: Heikki Linnakangas +X-X-Sender: hlinnaka@kosh.hut.fi +To: =?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= +cc: pgsql-hackers@postgresql.org +Subject: Re: [HACKERS] Two-phase commit for 8.1 +In-Reply-To: <41F3699B.2060608@cybertec.at> +Message-ID: +References: + <20050119165747.U47533@ganymede.hub.org> <1115.1106181723@sss.pgh.pa.us> + <41F3699B.2060608@cybertec.at> +MIME-Version: 1.0 +Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed +Content-Transfer-Encoding: 8BIT +X-TKK-Virus-Scanned: by amavisd-new-2.1.2-hutcc at katosiko.hut.fi +X-Virus-Scanned: by amavisd-new at hub.org +X-Mailing-List: pgsql-hackers +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +X-Virus-Scanned: by amavisd-new at hub.org +X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on + candle.pha.pa.us +X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham + version=2.61 +Status: OR + +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 some thinking, but shouldn't be much work. + +As the patch gets more attention, I'm sure more issues will come up. + +- Heikki + +---------------------------(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+M63434=pgman=candle.pha.pa.us@postgresql.org Sun Jan 23 09:15:24 2005 +Return-path: +Received: from svr1.postgresql.org (svr1.postgresql.org [200.46.204.71]) + by candle.pha.pa.us (8.11.6/8.11.6) with ESMTP id j0NFFMw25305 + for ; Sun, 23 Jan 2005 10:15:23 -0500 (EST) +Received: from localhost (unknown [200.46.204.144]) + by svr1.postgresql.org (Postfix) with ESMTP id 3A5DA3A3BE7 + for ; Sun, 23 Jan 2005 15:15:16 +0000 (GMT) +Received: from svr1.postgresql.org ([200.46.204.71]) + by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) + with ESMTP id 99539-08 for ; + Sun, 23 Jan 2005 15:15:11 +0000 (GMT) +Received: from postgresql.org (svr1.postgresql.org [200.46.204.71]) + by svr1.postgresql.org (Postfix) with ESMTP id 4A7C43A1A03 + for ; Sun, 23 Jan 2005 15:15:15 +0000 (GMT) +X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org +Received: from localhost (unknown [200.46.204.144]) + by svr1.postgresql.org (Postfix) with ESMTP id 08EA83A5242 + for ; Sun, 23 Jan 2005 15:13:52 +0000 (GMT) +Received: from svr1.postgresql.org ([200.46.204.71]) + by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) + with ESMTP id 00254-02 + for ; + Sun, 23 Jan 2005 15:13:46 +0000 (GMT) +Received: from sunsite.dcc.uchile.cl (sunsite.dcc.uchile.cl [192.80.24.2]) + by svr1.postgresql.org (Postfix) with ESMTP id AF7C83A520D + for ; Sun, 23 Jan 2005 15:13:48 +0000 (GMT) +Received: from anakena.dcc.uchile.cl ([192.80.24.3]) + by sunsite.dcc.uchile.cl (8.12.11/8.12.11) with ESMTP id j0NFDbu4014311; + Sun, 23 Jan 2005 12:13:42 -0300 (CLST) +Received: by anakena.dcc.uchile.cl (Postfix, from userid 4151) + id 666A5527DA; Sun, 23 Jan 2005 12:13:37 -0300 (CLST) +Date: Sun, 23 Jan 2005 12:13:37 -0300 +From: Alvaro Herrera +To: Heikki Linnakangas +cc: =?iso-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= , + pgsql-hackers@postgresql.org +Subject: Re: [HACKERS] Two-phase commit for 8.1 +Message-ID: <20050123151337.GD4406@dcc.uchile.cl> +References: <20050119165747.U47533@ganymede.hub.org> <1115.1106181723@sss.pgh.pa.us> <41F3699B.2060608@cybertec.at> +MIME-Version: 1.0 +Content-Type: text/plain; charset=us-ascii +Content-Disposition: inline +In-Reply-To: +User-Agent: Mutt/1.5.6i +X-Virus-Scanned: by amavisd-new at hub.org +X-Mailing-List: pgsql-hackers +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +X-Virus-Scanned: by amavisd-new at hub.org +X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on + candle.pha.pa.us +X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham + version=2.61 +Status: OR + +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 reassign them to a pseudo process? Are there +possibilities of deadlock somewhere? + +-- +Alvaro Herrera () +Thou shalt study thy libraries and strive not to reinvent them without +cause, that thy code may be short and readable and thy days pleasant +and productive. (7th Commandment for C Programmers) + +---------------------------(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+M63438=pgman=candle.pha.pa.us@postgresql.org Sun Jan 23 11:36:40 2005 +Return-path: +Received: from svr1.postgresql.org (svr1.postgresql.org [200.46.204.71]) + by candle.pha.pa.us (8.11.6/8.11.6) with ESMTP id j0NHaaw11289 + for ; Sun, 23 Jan 2005 12:36:37 -0500 (EST) +Received: from localhost (unknown [200.46.204.144]) + by svr1.postgresql.org (Postfix) with ESMTP id 7A1633A4A77 + for ; Sun, 23 Jan 2005 17:36:32 +0000 (GMT) +Received: from svr1.postgresql.org ([200.46.204.71]) + by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) + with ESMTP id 13791-10 for ; + Sun, 23 Jan 2005 17:36:31 +0000 (GMT) +Received: from postgresql.org (svr1.postgresql.org [200.46.204.71]) + by svr1.postgresql.org (Postfix) with ESMTP id 852863A49EC + for ; Sun, 23 Jan 2005 17:36:31 +0000 (GMT) +X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org +Received: from localhost (unknown [200.46.204.144]) + by svr1.postgresql.org (Postfix) with ESMTP id 252743A4B01 + for ; Sun, 23 Jan 2005 17:35:26 +0000 (GMT) +Received: from svr1.postgresql.org ([200.46.204.71]) + by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) + with ESMTP id 13880-08 + for ; + Sun, 23 Jan 2005 17:35:17 +0000 (GMT) +Received: from smtp-1.hut.fi (smtp-1.hut.fi [130.233.228.91]) + by svr1.postgresql.org (Postfix) with ESMTP id 5B7633A19A5 + for ; Sun, 23 Jan 2005 17:35:12 +0000 (GMT) +Received: from localhost (katosiko.hut.fi [130.233.228.115]) + by smtp-1.hut.fi (8.12.10/8.12.10) with ESMTP id j0NHYwms014946; + Sun, 23 Jan 2005 19:34:58 +0200 +Received: from smtp-1.hut.fi ([130.233.228.91]) + by localhost (katosiko.hut.fi [130.233.228.115]) (amavisd-new, port 10024) + with LMTP id 04068-01; Sun, 23 Jan 2005 19:34:57 +0200 (EET) +Received: from kosh.hut.fi (kosh.hut.fi [130.233.228.10]) + by smtp-1.hut.fi (8.12.10/8.12.10) with ESMTP id j0NHWt0g014723; + Sun, 23 Jan 2005 19:32:55 +0200 +Date: Sun, 23 Jan 2005 19:32:55 +0200 (EET) +From: Heikki Linnakangas +X-X-Sender: hlinnaka@kosh.hut.fi +To: Alvaro Herrera +cc: =?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= , + pgsql-hackers@postgresql.org +Subject: Re: [HACKERS] Two-phase commit for 8.1 +In-Reply-To: <20050123151337.GD4406@dcc.uchile.cl> +Message-ID: +References: + <20050119165747.U47533@ganymede.hub.org> <1115.1106181723@sss.pgh.pa.us> + <41F3699B.2060608@cybertec.at> + <20050123151337.GD4406@dcc.uchile.cl> +MIME-Version: 1.0 +Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed +X-TKK-Virus-Scanned: by amavisd-new-2.1.2-hutcc at katosiko.hut.fi +X-Virus-Scanned: by amavisd-new at hub.org +X-Mailing-List: pgsql-hackers +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +X-Virus-Scanned: by amavisd-new at hub.org +X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on + candle.pha.pa.us +X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham + version=2.61 +Status: OR + +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 locks and then reacquire +> them, or do you reassign them to a pseudo process? + +I reassign them to a pseudo process (persistedLocksProc). + +Much of the changes in lock.c are just about moving code around. +Some copy-paste code has been put in functions. LockAcquire has been +changed to take PGPROC as an argument, so that locks can be acquired on +behalf of the pseudo process. + +Then there's completely new code for persisting locks on PREPARE +TRANSACTION and reacquiring them on recovery. + +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. + +> Are there possibilities of deadlock somewhere? + +Not that I know of. + +- Heikki + +---------------------------(end of broadcast)--------------------------- +TIP 5: Have you checked our extensive FAQ? + + http://www.postgresql.org/docs/faq + +From pgsql-hackers-owner+M63788=pgman=candle.pha.pa.us@postgresql.org Mon Jan 31 09:35:11 2005 +Return-path: +Received: from svr1.postgresql.org (svr1.postgresql.org [200.46.204.71]) + by candle.pha.pa.us (8.11.6/8.11.6) with ESMTP id j0VFZAw06420 + for ; Mon, 31 Jan 2005 10:35:10 -0500 (EST) +Received: from localhost (unknown [200.46.204.144]) + by svr1.postgresql.org (Postfix) with ESMTP id 46B838B9C28 + for ; Mon, 31 Jan 2005 15:35:07 +0000 (GMT) +Received: from svr1.postgresql.org ([200.46.204.71]) + by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) + with ESMTP id 86064-08 for ; + Mon, 31 Jan 2005 15:35:03 +0000 (GMT) +Received: from postgresql.org (svr1.postgresql.org [200.46.204.71]) + by svr1.postgresql.org (Postfix) with ESMTP id 5D6918B9E6A + for ; Mon, 31 Jan 2005 15:23:48 +0000 (GMT) +X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org +Received: from localhost (unknown [200.46.204.144]) + by svr1.postgresql.org (Postfix) with ESMTP id E92DF8B9CC6 + for ; Mon, 31 Jan 2005 15:21:14 +0000 (GMT) +Received: from svr1.postgresql.org ([200.46.204.71]) + by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) + with ESMTP id 83005-03 + for ; + Mon, 31 Jan 2005 15:21:04 +0000 (GMT) +Received: from sunsite.dcc.uchile.cl (sunsite.dcc.uchile.cl [192.80.24.2]) + by svr1.postgresql.org (Postfix) with ESMTP id A315B8B9D3E + for ; Mon, 31 Jan 2005 15:01:43 +0000 (GMT) +Received: from anakena.dcc.uchile.cl ([192.80.24.3]) + by sunsite.dcc.uchile.cl (8.12.11/8.12.11) with ESMTP id j0VF1KCf026107; + Mon, 31 Jan 2005 12:01:24 -0300 (CLST) +Received: by anakena.dcc.uchile.cl (Postfix, from userid 4151) + id F287A52515; Mon, 31 Jan 2005 12:01:19 -0300 (CLST) +Date: Mon, 31 Jan 2005 12:01:19 -0300 +From: Alvaro Herrera +To: Heikki Linnakangas +cc: =?iso-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= , + pgsql-hackers@postgresql.org +Subject: Re: [HACKERS] Two-phase commit for 8.1 +Message-ID: <20050131150119.GI22141@dcc.uchile.cl> +References: <20050119165747.U47533@ganymede.hub.org> <1115.1106181723@sss.pgh.pa.us> <41F3699B.2060608@cybertec.at> <20050123151337.GD4406@dcc.uchile.cl> +MIME-Version: 1.0 +Content-Type: text/plain; charset=iso-8859-1 +Content-Disposition: inline +Content-Transfer-Encoding: 8bit +In-Reply-To: +User-Agent: Mutt/1.5.6i +X-Virus-Scanned: by amavisd-new at hub.org +X-Mailing-List: pgsql-hackers +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +X-Virus-Scanned: by amavisd-new at hub.org +X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on + candle.pha.pa.us +X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham + version=2.61 +Status: OR + +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 could be merged +right now, and the actual 2PC stuff would be smaller and easier to +review. + +You'd only need a committer to actually commit the initial patch ... + +-- +Alvaro Herrera () +"No hay cielo posible sin hundir nuestras raíces + en la profundidad de la tierra" (Malucha Pinto) + +---------------------------(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+M66050@postgresql.org Wed Apr 6 10:04:39 2005 +Return-path: +Received: from svr1.postgresql.org (svr1.postgresql.org [200.46.204.71]) + by candle.pha.pa.us (8.11.6/8.11.6) with ESMTP id j36E4cO20150 + for ; Wed, 6 Apr 2005 10:04:38 -0400 (EDT) +Received: from localhost (unknown [200.46.204.144]) + by svr1.postgresql.org (Postfix) with ESMTP id 248C2537FE + for ; Wed, 6 Apr 2005 15:04:32 +0100 (BST) +Received: from svr1.postgresql.org ([200.46.204.71]) + by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) + with ESMTP id 64844-06 for ; + Wed, 6 Apr 2005 14:04:32 +0000 (GMT) +Received: from postgresql.org (svr1.postgresql.org [200.46.204.71]) + by svr1.postgresql.org (Postfix) with ESMTP id D2EB5537F8 + for ; Wed, 6 Apr 2005 15:04:31 +0100 (BST) +X-Original-To: pgsql-hackers-postgresql.org@localhost.postgresql.org +Received: from localhost (unknown [200.46.204.144]) + by svr1.postgresql.org (Postfix) with ESMTP id AA7FE539FA + for ; Wed, 6 Apr 2005 15:01:33 +0100 (BST) +Received: from svr1.postgresql.org ([200.46.204.71]) + by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) + with ESMTP id 62842-09 + for ; + Wed, 6 Apr 2005 14:01:26 +0000 (GMT) +Received: from smtp-1.hut.fi (smtp-1.hut.fi [130.233.228.91]) + by svr1.postgresql.org (Postfix) with ESMTP id F02FD538C8 + for ; Wed, 6 Apr 2005 15:01:22 +0100 (BST) +Received: from localhost (katosiko.hut.fi [130.233.228.115]) + by smtp-1.hut.fi (8.12.10/8.12.10) with ESMTP id j36E11Yl028611; + Wed, 6 Apr 2005 17:01:01 +0300 +Received: from smtp-1.hut.fi ([130.233.228.91]) + by localhost (katosiko.hut.fi [130.233.228.115]) (amavisd-new, port 10024) + with LMTP id 22125-05; Wed, 6 Apr 2005 17:01:00 +0300 (EEST) +Received: from kosh.hut.fi (kosh.hut.fi [130.233.228.10]) + by smtp-1.hut.fi (8.12.10/8.12.10) with ESMTP id j36DxlPJ028376; + Wed, 6 Apr 2005 16:59:48 +0300 +Date: Wed, 6 Apr 2005 16:59:47 +0300 (EEST) +From: Heikki Linnakangas +X-X-Sender: hlinnaka@kosh.hut.fi +To: Alvaro Herrera +cc: pgsql-hackers@postgresql.org +Subject: Re: [HACKERS] Two phase commit +In-Reply-To: <20050405230731.GA26960@surnet.cl> +Message-ID: +References: <20050405230731.GA26960@surnet.cl> +MIME-Version: 1.0 +Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed +X-TKK-Virus-Scanned: by amavisd-new-2.1.2-hutcc at katosiko.hut.fi +X-Virus-Scanned: by amavisd-new at hub.org +X-Mailing-List: pgsql-hackers +Precedence: bulk +Sender: pgsql-hackers-owner@postgresql.org +X-Virus-Scanned: by amavisd-new at hub.org +Status: OR + +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 if you hackers could take a serious look at it and tell +what needs to be done to get it finally committed. + +I've been busy with other things and haven't had the time to push it. + +I try to update my "project page" every time I update the patch: + +http://www.hut.fi/~hlinnaka/pgsql/ + +There isn't any big issues left as far as I know. + +- Heikki + +---------------------------(end of broadcast)--------------------------- +TIP 2: you can get off all lists at once with the unregister command + (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) + diff --git a/doc/TODO.detail/pitr b/doc/TODO.detail/pitr new file mode 100644 index 0000000000..d4d4c41404 --- /dev/null +++ b/doc/TODO.detail/pitr @@ -0,0 +1,827 @@ +From pgsql-admin-owner+M15281=pgman=candle.pha.pa.us@postgresql.org Thu Oct 21 18:57:36 2004 +Return-path: +Received: from svr1.postgresql.org (svr1.postgresql.org [200.46.204.71]) + by candle.pha.pa.us (8.11.6/8.11.6) with ESMTP id i9LLvYf17059 + for ; Thu, 21 Oct 2004 17:57:34 -0400 (EDT) +Received: from localhost (unknown [200.46.204.144]) + by svr1.postgresql.org (Postfix) with ESMTP id 79D9132A71A + for ; Thu, 21 Oct 2004 22:57:29 +0100 (BST) +Received: from svr1.postgresql.org ([200.46.204.71]) + by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) + with ESMTP id 80515-02 for ; + Thu, 21 Oct 2004 21:57:26 +0000 (GMT) +Received: from postgresql.org (svr1.postgresql.org [200.46.204.71]) + by svr1.postgresql.org (Postfix) with ESMTP id 1209432A70E + for ; Thu, 21 Oct 2004 22:57:29 +0100 (BST) +X-Original-To: pgsql-admin-postgresql.org@localhost.postgresql.org +Received: from localhost (unknown [200.46.204.144]) + by svr1.postgresql.org (Postfix) with ESMTP id 4B39932A6C3 + for ; Thu, 21 Oct 2004 22:51:01 +0100 (BST) +Received: from svr1.postgresql.org ([200.46.204.71]) + by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) + with ESMTP id 78125-02 + for ; + Thu, 21 Oct 2004 21:50:48 +0000 (GMT) +Received: from news.hub.org (news.hub.org [200.46.204.72]) + by svr1.postgresql.org (Postfix) with ESMTP id 27F0632A6C2 + for ; Thu, 21 Oct 2004 22:50:49 +0100 (BST) +Received: from news.hub.org (news.hub.org [200.46.204.72]) + by news.hub.org (8.12.9/8.12.9) with ESMTP id i9LLojJ7079086 + for ; Thu, 21 Oct 2004 21:50:45 GMT + (envelope-from news@news.hub.org) +Received: (from news@localhost) + by news.hub.org (8.12.9/8.12.9/Submit) id i9LLnd7p078783 + for pgsql-admin@postgresql.org; Thu, 21 Oct 2004 21:49:39 GMT +From: Gaetano Mendola +X-Newsgroups: comp.databases.postgresql.admin +Subject: Re: [ADMIN] replication using WAL archives +Date: Thu, 21 Oct 2004 23:49:35 +0200 +Organization: PYRENET Midi-pyrenees Provider +Lines: 216 +Message-ID: <41782EEF.5040708@bigfoot.com> +References: <002801c4b739$68450870$7201a8c0@mst1x5r347kymb> <1098384082.15573.14.camel@camel> +MIME-Version: 1.0 +Content-Type: multipart/mixed; + boundary="------------060900090803090101060101" +X-Complaints-To: abuse@pyrenet.fr +cc: iain@mst.co.jp +To: Robert Treat +User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) +X-Accept-Language: en-us, en +In-Reply-To: <1098384082.15573.14.camel@camel> +X-Enigmail-Version: 0.86.1.0 +X-Enigmail-Supports: pgp-inline, pgp-mime +To: pgsql-admin@postgresql.org +X-Virus-Scanned: by amavisd-new at hub.org +X-Mailing-List: pgsql-admin +Precedence: bulk +Sender: pgsql-admin-owner@postgresql.org +X-Virus-Scanned: by amavisd-new at hub.org +X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on + candle.pha.pa.us +X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham + version=2.61 +Status: OR + +This is a multi-part message in MIME format. +--------------060900090803090101060101 +Content-Type: text/plain; charset=ISO-8859-1; format=flowed +Content-Transfer-Encoding: 7bit + +Robert Treat wrote: +> On Thu, 2004-10-21 at 02:44, Iain wrote: +> +>>Hi, +>> +>>I thought I read something about this in relation to v8, but I can't +>>find any reference to it now... is it (or will it be) possible to do +>>master-slave style database replication by transmitting log files to the +>>standby server and having it process them? +>> +> +> +> I'm not certain if this is 8.0, but some folks have created a working +> version against the 8.0 code that will do something like this. Search +> the pgsql-hacker mail list archives for more information on it. + +I sent a post on hackers, I put it here: + +======================================================================= +Hi all, +I seen that Eric Kerin did the work suggested by Tom about +how to use the PITR in order to have an hot spare postgres, +writing a C program. + +I did the same writing 2 shell scripts, one of them perform +the restore the other one deliver the partial filled wal and +check if the postmaster is alive ( check if the pid process +still exist ). + +With these two scripts I'm able to have an hot spare installation, +and the spare one go alive when the first postmaster dies. + +How test it: + +1) Master node: + modify postgresql.conf using: + +~ archive_command = 'cp %p /mnt/server/archivedir/%f' + +~ launch postgres and perform a backup as doc + +~ http://developer.postgresql.org/docs/postgres/backup-online.html + + suggest to do + + launch the script: + + partial_wal_deliver.sh /mnt/server/partialdir + +~ this script will delivery each 10 seconds the "current" wal file, +~ and touch the "alive" file in order to notify the spare node that +~ the master node is up and running + + +2) Spare node: + create a recovery.conf with the line: + +~ restore_command = 'restore.sh /mnt/server/archivedir/%f %p /mnt/server/partialdir' + +~ replace the content of data directory with the backup performed at point 1, +~ remove any file present in the pg_xlog directory ( leaving there the archive_status +~ directory ) and remove the postmaster.pid file ( this is necessary if you are running +~ the spare postgres on the same hw ). + +~ launch the postmaster, the restore will continue till the "alive" file present in the +~ /mnt/server/partialdir directory is not updated for 60 seconds ( you can modify this +~ values inside the restore.sh script ). + +Be sure that restore.sh and all directories involved are accessible + +Let me know. + + +This is a first step, of course, as Eric Kerin did, is better port these script +in C and make it more robust. + +Postgres can help this process, as suggested by Tom creating a pg_current_wal() +or even better having two new GUC parameters: archive_current_wal_command and +archive_current_wal_delay. + +I problem I discover during the tests is that if you shut down the spare node +and the restore_command is still waiting for a file then the postmaster will never +exit :-( +========================================================================== + +I hope that is clear. + + + +Regards +Gaetano Mendola + + + +--------------060900090803090101060101 +Content-Type: text/plain; + name="restore.sh" +Content-Transfer-Encoding: 7bit +Content-Disposition: inline; + filename="restore.sh" + +#!/bin/bash + + +SOURCE=$1 +TARGET=$2 +PARTIAL=$3 + +SIZE_EXPECTED=16777216 #bytes 16 MB +DIED_TIME=60 #seconds + +function test_existence +{ + if [ -f ${SOURCE} ] + then + COUNTER=0 + + #I have to check if the file is begin copied + #I assume that it will reach the right + #size in a few seconds + + while [ $(stat -c '%s' ${SOURCE} ) -lt $SIZE_EXPECTED ] + do + sleep 1 + let COUNTER+=1 + if [ 20 -lt $COUNTER ] + then + exit 1 # BAILING OUT + fi + done + + cp $SOURCE $TARGET + exit 0 + fi + echo ${SOURCE}"> not found" + + #if is looking for a history file and not exist + #I have suddenly exit + echo $SOURCE | grep history > /dev/null 2>&1 && exit 1 +} + + +while [ 1 ] +do + + test_existence + + #CHECK IF THE MASTER IS ALIVE + DELTA_TIME=$(( $( date +'%s' ) - $( stat -c '%Z' ${PARTIAL}/alive ) )) + if [ $DIED_TIME -lt $DELTA_TIME ] + then + echo "Master is dead..." + # Master is dead + CURRENT_WAL=$( basename $SOURCE ) + echo "Partial: " ${PARTIAL} + echo "Current wal: " ${CURRENT_WAL} + echo "Target: " ${TARGET} + cp ${PARTIAL}/${CURRENT_WAL}.partial ${TARGET} > /dev/null 2>&1 && exit 0 + exit 1 + fi + + sleep 1 + +done + +--------------060900090803090101060101 +Content-Type: text/plain; + name="partial_wal_deliver.sh" +Content-Transfer-Encoding: 7bit +Content-Disposition: inline; + filename="partial_wal_deliver.sh" + +#!/bin/bash + +PID=$1 +PARTIAL=$2 +PGXLOG=$3 + +function copy_last_wal +{ + FILE=$( ls -t1p $PGXLOG | grep -v / | head -1 ) + + echo "Last Wal> " $FILE + + cp ${PGXLOG}/${FILE} ${PARTIAL}/${FILE}.tmp + mv ${PARTIAL}/${FILE}.tmp ${PARTIAL}/${FILE}.partial + find ${PARTIAL} -name *.partial | grep -v ${FILE} | xargs -i rm -fr {} +} + + +while [ 1 ] +do + ps --pid $PID > /dev/null 2>&1 + ALIVE=$? + + if [ "${ALIVE}" == "1" ] + then + #The process is dead + echo "Process dead" + copy_last_wal + exit 1 + fi + + #The process still exist + touch ${PARTIAL}/alive + copy_last_wal + + sleep 10 +done + +--------------060900090803090101060101 +Content-Type: text/plain +Content-Disposition: inline +Content-Transfer-Encoding: 8bit +MIME-Version: 1.0 + + +---------------------------(end of broadcast)--------------------------- +TIP 5: Have you checked our extensive FAQ? + + http://www.postgresql.org/docs/faqs/FAQ.html + +--------------060900090803090101060101-- + +From pgsql-admin-owner+M15295=pgman=candle.pha.pa.us@postgresql.org Fri Oct 22 06:32:38 2004 +Return-path: +Received: from svr1.postgresql.org (svr1.postgresql.org [200.46.204.71]) + by candle.pha.pa.us (8.11.6/8.11.6) with ESMTP id i9M9Waf18397 + for ; Fri, 22 Oct 2004 05:32:36 -0400 (EDT) +Received: from localhost (unknown [200.46.204.144]) + by svr1.postgresql.org (Postfix) with ESMTP id 9C9A532AC61 + for ; Fri, 22 Oct 2004 10:32:32 +0100 (BST) +Received: from svr1.postgresql.org ([200.46.204.71]) + by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) + with ESMTP id 53654-01 for ; + Fri, 22 Oct 2004 09:32:26 +0000 (GMT) +Received: from postgresql.org (svr1.postgresql.org [200.46.204.71]) + by svr1.postgresql.org (Postfix) with ESMTP id 3132D32AC53 + for ; Fri, 22 Oct 2004 10:32:32 +0100 (BST) +X-Original-To: pgsql-admin-postgresql.org@localhost.postgresql.org +Received: from localhost (unknown [200.46.204.144]) + by svr1.postgresql.org (Postfix) with ESMTP id DC46E32A095 + for ; Fri, 22 Oct 2004 10:23:07 +0100 (BST) +Received: from svr1.postgresql.org ([200.46.204.71]) + by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) + with ESMTP id 49812-03 + for ; + Fri, 22 Oct 2004 09:22:52 +0000 (GMT) +Received: from cmailg3.svr.pol.co.uk (cmailg3.svr.pol.co.uk [195.92.195.173]) + by svr1.postgresql.org (Postfix) with ESMTP id 5AEA6329F2F + for ; Fri, 22 Oct 2004 10:22:57 +0100 (BST) +Received: from modem-21.monkey.dialup.pol.co.uk ([217.135.208.21] helo=Nightingale) + by cmailg3.svr.pol.co.uk with smtp (Exim 4.41) + id 1CKvdM-0005eh-NO; Fri, 22 Oct 2004 10:22:53 +0100 +Message-ID: <011a01c4b818$b7370a20$06e887d9@Nightingale> +From: "Simon Riggs" +To: "Gaetano Mendola" , + "Robert Treat" , +cc: +References: <002801c4b739$68450870$7201a8c0@mst1x5r347kymb> <1098384082.15573.14.camel@camel> <41782EEF.5040708@bigfoot.com> +Subject: Re: [ADMIN] replication using WAL archives +Date: Fri, 22 Oct 2004 10:22:54 +0100 +MIME-Version: 1.0 +Content-Type: text/plain; + charset="iso-8859-1" +Content-Transfer-Encoding: 7bit +X-Priority: 3 +X-MSMail-Priority: Normal +X-Mailer: Microsoft Outlook Express 6.00.2800.1409 +X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 +X-Virus-Scanned: by amavisd-new at hub.org +X-Mailing-List: pgsql-admin +Precedence: bulk +Sender: pgsql-admin-owner@postgresql.org +X-Virus-Scanned: by amavisd-new at hub.org +X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on + candle.pha.pa.us +X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham + version=2.61 +Status: OR + +> Gaetano Mendola wrote +> Postgres can help this process, as suggested by Tom creating a +pg_current_wal() +> or even better having two new GUC parameters: archive_current_wal_command +and +> archive_current_wal_delay. + +OK, we can modify the archiver to do this as well as the archive-when-full +functionality. I'd already agreed to do something similar for 8.1 + +PROPOSAL: +By default, archive_max_delay would be 10 seconds. +By default, archive_current_wal_command is not set. +If archive_current_wal_command is not set, the archiver will archive a file +using archive_command only when the file is full. +If archive_current_wal_command is set, the archiver would archive a file +whichever of these occurs first... +- it is full +- the archive_max_delay timeout occurs (default: disabled) +...as you can see I've renamed archive_current_wal_delay to reflect the fact +that there is an interaction between the current mechanism (only when full) +and this additional mechanism (no longer than X secs between log files). +With that design, if the logs are being created quickly enough, then a +partial log file is never created, only full ones. + +When an xlog file is archived because it is full, then it is sent to both +archive_current_wal_command and archive_command (in that order). When the +timeout occurs and we have a partial xlog file, it would only be sent to +archive_current_wal_command. It may also be desirable to not use +archive_command at all, only to use archive_current_wal_command. That's not +currently possible because archive_command is the switch by which all of the +archive functioanlity is enabled, so you can't actually turn this off. + +There is already a timeout feature designed into archiver for safety...so I +can make that read the GUCs, above and act accordingly. + +There is an unresolved resilience issue: if the archiver goes down (or +whatever does the partial_wal copy functionality) then it it is possible +that users will continue writing to the database and creating xlog records. +It would be up to the user to define how to handle records that had been +committed to the first database in the interim before cutover. It would also +be up to the user to shut down the first node from the second - Shoot the +Other Node in the Head, as its known. All of that is up to the second node, +and as Tom says, is "the hard part"....I'm not proposing to do anything +about that at this stage, since it is implementation dependant. + +I was thinking perhaps to move to having variable size xlog files, since +their contents are now variable - no padded records at EOF. If we did that, +then the archiver could simply issue a "switch logfile" and then the +archiver would cut in anyway to copy away the xlog. Having said that it is +lots easier just to put a blind timeout in the archiver and copy the file - +though I'm fairly uneasy about the point that we'd be ignoring the fact that +many people are still writing to it. But I propose doing the easy way.... + +Thoughts? + += - = - = + +Gaetano - skim-reading your script, how do you handle the situation when a +new xlog file has been written within 10 seconds? That way the current file +number will have jumped by 2, so when your script looks for the "Last wal" +using head -1 it will find the N+2 and the intermediate file will never be +copied. Looks like a problem to me... + +> I problem I discover during the tests is that if you shut down the spare +node +> and the restore_command is still waiting for a file then the postmaster +will never +> exit :-( + +Hmm....Are you reporting this as a bug for 8.0? It's not on the bug list... + +Do we consider that to be desirable or not? + +Best Regards, Simon Riggs + + + +---------------------------(end of broadcast)--------------------------- +TIP 2: you can get off all lists at once with the unregister command + (send "unregister YourEmailAddressHere" to majordomo@postgresql.org) + +From pgsql-admin-owner+M15302=pgman=candle.pha.pa.us@postgresql.org Fri Oct 22 13:56:14 2004 +Return-path: +Received: from svr1.postgresql.org (svr1.postgresql.org [200.46.204.71]) + by candle.pha.pa.us (8.11.6/8.11.6) with ESMTP id i9MGuCf28637 + for ; Fri, 22 Oct 2004 12:56:13 -0400 (EDT) +Received: from localhost (unknown [200.46.204.144]) + by svr1.postgresql.org (Postfix) with ESMTP id 54E77EAEDAA + for ; Fri, 22 Oct 2004 17:55:51 +0100 (BST) +Received: from svr1.postgresql.org ([200.46.204.71]) + by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) + with ESMTP id 86116-09 for ; + Fri, 22 Oct 2004 16:55:57 +0000 (GMT) +Received: from postgresql.org (svr1.postgresql.org [200.46.204.71]) + by svr1.postgresql.org (Postfix) with ESMTP id 0EC98EAEDA7 + for ; Fri, 22 Oct 2004 17:55:51 +0100 (BST) +X-Original-To: pgsql-admin-postgresql.org@localhost.postgresql.org +Received: from localhost (unknown [200.46.204.144]) + by svr1.postgresql.org (Postfix) with ESMTP id 5DB98EAEDBE + for ; Fri, 22 Oct 2004 17:45:13 +0100 (BST) +Received: from svr1.postgresql.org ([200.46.204.71]) + by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) + with ESMTP id 82473-08 + for ; + Fri, 22 Oct 2004 16:45:11 +0000 (GMT) +Received: from pns.mm.eutelsat.org (pns.mm.eutelsat.org [194.214.173.227]) + by svr1.postgresql.org (Postfix) with ESMTP id E49F0EAEDB5 + for ; Fri, 22 Oct 2004 17:45:00 +0100 (BST) +Received: from nts-03.mm.eutelsat.org (localhost [127.0.0.1]) + by pns.mm.eutelsat.org (8.11.6/linuxconf) with ESMTP id i9MGh0U26124; + Fri, 22 Oct 2004 18:43:01 +0200 +Received: from [127.0.0.1] (accesspoint.mm.eutelsat.org [194.214.173.4]) + by nts-03.mm.eutelsat.org (8.11.6/linuxconf) with ESMTP id i9MGj5f09681; + Fri, 22 Oct 2004 18:45:05 +0200 +Message-ID: <4179390B.10700@bigfoot.com> +Date: Fri, 22 Oct 2004 18:44:59 +0200 +From: Gaetano Mendola +User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) +X-Accept-Language: en-us, en +MIME-Version: 1.0 +To: Simon Riggs +cc: Robert Treat , pgsql-admin@postgresql.org, + iain@mst.co.jp +Subject: Re: [ADMIN] replication using WAL archives +References: <002801c4b739$68450870$7201a8c0@mst1x5r347kymb> <1098384082.15573.14.camel@camel> <41782EEF.5040708@bigfoot.com> <011a01c4b818$b7370a20$06e887d9@Nightingale> +In-Reply-To: <011a01c4b818$b7370a20$06e887d9@Nightingale> +X-Enigmail-Version: 0.86.1.0 +X-Enigmail-Supports: pgp-inline, pgp-mime +Content-Type: text/plain; charset=ISO-8859-1; format=flowed +Content-Transfer-Encoding: 7bit +X-Virus-Scanned: by amavisd-new at hub.org +X-Mailing-List: pgsql-admin +Precedence: bulk +Sender: pgsql-admin-owner@postgresql.org +X-Virus-Scanned: by amavisd-new at hub.org +X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on + candle.pha.pa.us +X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham + version=2.61 +Status: OR + +-----BEGIN PGP SIGNED MESSAGE----- +Hash: SHA1 + +Simon Riggs wrote: +|>Gaetano Mendola wrote +|>Postgres can help this process, as suggested by Tom creating a +| +| pg_current_wal() +| +|>or even better having two new GUC parameters: archive_current_wal_command +| +| and +| +|>archive_current_wal_delay. +| +| +| OK, we can modify the archiver to do this as well as the archive-when-full +| functionality. I'd already agreed to do something similar for 8.1 +| +| PROPOSAL: +| By default, archive_max_delay would be 10 seconds. +| By default, archive_current_wal_command is not set. +| If archive_current_wal_command is not set, the archiver will archive a file +| using archive_command only when the file is full. +| If archive_current_wal_command is set, the archiver would archive a file +| whichever of these occurs first... +| - it is full +| - the archive_max_delay timeout occurs (default: disabled) +| ...as you can see I've renamed archive_current_wal_delay to reflect the fact +| that there is an interaction between the current mechanism (only when full) +| and this additional mechanism (no longer than X secs between log files). +| With that design, if the logs are being created quickly enough, then a +| partial log file is never created, only full ones. +| +| When an xlog file is archived because it is full, then it is sent to both +| archive_current_wal_command and archive_command (in that order). When the +| timeout occurs and we have a partial xlog file, it would only be sent to +| archive_current_wal_command. It may also be desirable to not use +| archive_command at all, only to use archive_current_wal_command. That's not +| currently possible because archive_command is the switch by which all of the +| archive functioanlity is enabled, so you can't actually turn this off. + +It seems good to me, the script behind archive command can be a nop if someone +want use the archive_current_wal_command + + +| = - = - = +| +| Gaetano - skim-reading your script, how do you handle the situation when a +| new xlog file has been written within 10 seconds? That way the current file +| number will have jumped by 2, so when your script looks for the "Last wal" +| using head -1 it will find the N+2 and the intermediate file will never be +| copied. Looks like a problem to me... + + +Yes, the only window failure I seen ( but I don't know if it's possible ) + +Master: +~ log N created + log N filled + archive log N + log N+1 created + log N+1 filled +~ log N+2 created +~ <---- the master die here before to archive the log N+1 +~ archive log N+1 + + +in this case as you underline tha last log archived is the N and the N+2 +partial wal is added to archived wal collection and in the recovery fase +the recovery stop after processing the log N. + +Is it possible that the postmaster create the N+2 file without finish to archive +the N+1 ? ( I suspect yes :-( ) + +The only cure I see here is to look for not archived WAL ( if possible ). + + +|>I problem I discover during the tests is that if you shut down the spare +|>node and the restore_command is still waiting for a file then the postmaster +|>will never exit :-( +| +| +| Hmm....Are you reporting this as a bug for 8.0? It's not on the bug list... + +For me is a behave to avoid. + + + +Regards +Gaetano Mendola + + + + + + + +-----BEGIN PGP SIGNATURE----- +Version: GnuPG v1.2.5 (MingW32) +Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org + +iD8DBQFBeTkJ7UpzwH2SGd4RAsMxAKCbV7W+wrGBocf2Ftlthm0egAlIWACgp87L +KU/YusyHuvT7jSFwZVKpP3M= +=rWZx +-----END PGP SIGNATURE----- + + +---------------------------(end of broadcast)--------------------------- +TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org + +From pgsql-admin-owner+M15303=pgman=candle.pha.pa.us@postgresql.org Fri Oct 22 14:43:36 2004 +Return-path: +Received: from svr1.postgresql.org (svr1.postgresql.org [200.46.204.71]) + by candle.pha.pa.us (8.11.6/8.11.6) with ESMTP id i9MHhZf06453 + for ; Fri, 22 Oct 2004 13:43:35 -0400 (EDT) +Received: from localhost (unknown [200.46.204.144]) + by svr1.postgresql.org (Postfix) with ESMTP id 01DD2EADBB7 + for ; Fri, 22 Oct 2004 18:43:13 +0100 (BST) +Received: from svr1.postgresql.org ([200.46.204.71]) + by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) + with ESMTP id 01872-03 for ; + Fri, 22 Oct 2004 17:43:19 +0000 (GMT) +Received: from postgresql.org (svr1.postgresql.org [200.46.204.71]) + by svr1.postgresql.org (Postfix) with ESMTP id 9E633EADAD4 + for ; Fri, 22 Oct 2004 18:43:12 +0100 (BST) +X-Original-To: pgsql-admin-postgresql.org@localhost.postgresql.org +Received: from localhost (unknown [200.46.204.144]) + by svr1.postgresql.org (Postfix) with ESMTP id C1133EAED89 + for ; Fri, 22 Oct 2004 18:31:20 +0100 (BST) +Received: from svr1.postgresql.org ([200.46.204.71]) + by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) + with ESMTP id 97130-03 + for ; + Fri, 22 Oct 2004 17:31:17 +0000 (GMT) +Received: from cmailm2.svr.pol.co.uk (cmailm2.svr.pol.co.uk [195.92.193.210]) + by svr1.postgresql.org (Postfix) with ESMTP id 276CAEADBBD + for ; Fri, 22 Oct 2004 18:31:07 +0100 (BST) +Received: from modem-558.snake.dialup.pol.co.uk ([62.137.114.46] helo=[192.168.0.102]) + by cmailm2.svr.pol.co.uk with esmtp (Exim 4.41) + id 1CL3G3-0001Tx-K5; Fri, 22 Oct 2004 18:31:20 +0100 +Subject: Re: [ADMIN] replication using WAL archives +From: Simon Riggs +To: Gaetano Mendola +cc: Robert Treat , pgsql-admin@postgresql.org, + iain@mst.co.jp +In-Reply-To: <4179390B.10700@bigfoot.com> +References: <002801c4b739$68450870$7201a8c0@mst1x5r347kymb> + <1098384082.15573.14.camel@camel> <41782EEF.5040708@bigfoot.com> + <011a01c4b818$b7370a20$06e887d9@Nightingale> <4179390B.10700@bigfoot.com> +Content-Type: text/plain +Organization: 2nd Quadrant +Message-ID: <1098466150.20926.13.camel@localhost.localdomain> +MIME-Version: 1.0 +X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) +Date: Fri, 22 Oct 2004 18:29:10 +0100 +Content-Transfer-Encoding: 7bit +X-Virus-Scanned: by amavisd-new at hub.org +X-Mailing-List: pgsql-admin +Precedence: bulk +Sender: pgsql-admin-owner@postgresql.org +X-Virus-Scanned: by amavisd-new at hub.org +X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on + candle.pha.pa.us +X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham + version=2.61 +Status: OR + +On Fri, 2004-10-22 at 17:44, Gaetano Mendola wrote: +> | Gaetano - skim-reading your script, how do you handle the situation when a +> | new xlog file has been written within 10 seconds? That way the current file +> | number will have jumped by 2, so when your script looks for the "Last wal" +> | using head -1 it will find the N+2 and the intermediate file will never be +> | copied. Looks like a problem to me... +> +> +> Yes, the only window failure I seen ( but I don't know if it's possible ) +> +> Master: +> ~ log N created +> log N filled +> archive log N +> log N+1 created +> log N+1 filled +> ~ log N+2 created +> ~ <---- the master die here before to archive the log N+1 +> ~ archive log N+1 +> +> +> in this case as you underline tha last log archived is the N and the N+2 +> partial wal is added to archived wal collection and in the recovery fase +> the recovery stop after processing the log N. +> +> Is it possible that the postmaster create the N+2 file without finish to archive +> the N+1 ? ( I suspect yes :-( ) +> +> The only cure I see here is to look for not archived WAL ( if possible ). +> + +Hmm...well you aren't looking for archived wal, you're just looking at +wal...which is a different thing... + +Situation I thought I saw was: + +- copy away current partial filled xlog N +- xlog N fills, N+1 starts +- xlog N+1 fills, N+2 starts +- copy away current partial filled xlog: N+2 (+10 secs later) + +i.e. if time to fill xlog (is ever) < time to copy away current xlog, +then you miss one. + +So problem: you can miss one and never know you've missed one until the +recovery can't find it, which it never returns from...so it just hangs. + +[Just so we're all clear: we're talking about Gaetano's script, not the +PostgreSQL archver. The postgresql archiver doesn't do it that way, so +it never misses one.] + +-- +Best Regards, Simon Riggs + + +---------------------------(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-admin-owner+M15306=pgman=candle.pha.pa.us@postgresql.org Fri Oct 22 17:56:07 2004 +Return-path: +Received: from svr1.postgresql.org (svr1.postgresql.org [200.46.204.71]) + by candle.pha.pa.us (8.11.6/8.11.6) with ESMTP id i9MKu6f05264 + for ; Fri, 22 Oct 2004 16:56:06 -0400 (EDT) +Received: from localhost (unknown [200.46.204.144]) + by svr1.postgresql.org (Postfix) with ESMTP id 4F4C2EAE4AE + for ; Fri, 22 Oct 2004 21:55:41 +0100 (BST) +Received: from svr1.postgresql.org ([200.46.204.71]) + by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) + with ESMTP id 62857-05 for ; + Fri, 22 Oct 2004 20:55:48 +0000 (GMT) +Received: from postgresql.org (svr1.postgresql.org [200.46.204.71]) + by svr1.postgresql.org (Postfix) with ESMTP id 095CEEAE4AC + for ; Fri, 22 Oct 2004 21:55:41 +0100 (BST) +X-Original-To: pgsql-admin-postgresql.org@localhost.postgresql.org +Received: from localhost (unknown [200.46.204.144]) + by svr1.postgresql.org (Postfix) with ESMTP id 3FC9BEAE486 + for ; Fri, 22 Oct 2004 21:50:48 +0100 (BST) +Received: from svr1.postgresql.org ([200.46.204.71]) + by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) + with ESMTP id 62565-02 + for ; + Fri, 22 Oct 2004 20:50:48 +0000 (GMT) +Received: from news.hub.org (news.hub.org [200.46.204.72]) + by svr1.postgresql.org (Postfix) with ESMTP id 06C49EAE46B + for ; Fri, 22 Oct 2004 21:50:40 +0100 (BST) +Received: from news.hub.org (news.hub.org [200.46.204.72]) + by news.hub.org (8.12.9/8.12.9) with ESMTP id i9MKolJB062812 + for ; Fri, 22 Oct 2004 20:50:48 GMT + (envelope-from news@news.hub.org) +Received: (from news@localhost) + by news.hub.org (8.12.9/8.12.9/Submit) id i9MKoRHh062731 + for pgsql-admin@postgresql.org; Fri, 22 Oct 2004 20:50:27 GMT +From: Gaetano Mendola +X-Newsgroups: comp.databases.postgresql.admin +Subject: Re: [ADMIN] replication using WAL archives +Date: Fri, 22 Oct 2004 22:50:34 +0200 +Organization: PYRENET Midi-pyrenees Provider +Lines: 39 +Message-ID: <4179729A.5020401@bigfoot.com> +References: <002801c4b739$68450870$7201a8c0@mst1x5r347kymb> <1098384082.15573.14.camel@camel> <41782EEF.5040708@bigfoot.com> <011a01c4b818$b7370a20$06e887d9@Nightingale> <4179390B.10700@bigfoot.com> <1098466150.20926.13.camel@localhost.localdomain> +MIME-Version: 1.0 +Content-Type: text/plain; charset=ISO-8859-1; format=flowed +Content-Transfer-Encoding: 7bit +X-Complaints-To: abuse@pyrenet.fr +To: Simon Riggs +User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) +X-Accept-Language: en-us, en +In-Reply-To: <1098466150.20926.13.camel@localhost.localdomain> +X-Enigmail-Version: 0.86.1.0 +X-Enigmail-Supports: pgp-inline, pgp-mime +To: pgsql-admin@postgresql.org +X-Virus-Scanned: by amavisd-new at hub.org +X-Mailing-List: pgsql-admin +Precedence: bulk +Sender: pgsql-admin-owner@postgresql.org +X-Virus-Scanned: by amavisd-new at hub.org +X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on + candle.pha.pa.us +X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham + version=2.61 +Status: OR + +Simon Riggs wrote: + + > Situation I thought I saw was: + > + > - copy away current partial filled xlog N + > - xlog N fills, N+1 starts + > - xlog N+1 fills, N+2 starts + > - copy away current partial filled xlog: N+2 (+10 secs later) + > + > i.e. if time to fill xlog (is ever) < time to copy away current xlog, + > then you miss one. + > + > So problem: you can miss one and never know you've missed one until the + > recovery can't find it, which it never returns from...so it just hangs. + +No. The restore.sh is not smart enough to know the last wal that must be +replayed, the only "smart thing" is to copy the supposed "current wal" in the +archive directory. + +The script hang (and is a feature not a bug) if and only if the master is alive +( at least I'm not seeing any other hang ). + +In your example in the archived directory will be present the files until logN +and logN+2 ( the current wal ) is in the partial directory, if the master die, +the restore.sh will copy logN+2 in the archived directory, the spare node will +execute restore.sh with file logN+1 as argument and if is not found then the +restore.sh will exit. + + +Regards +Gaetano Mendola + + + + + + + + + +---------------------------(end of broadcast)--------------------------- +TIP 8: explain analyze is your friend +