diff --git a/doc/TODO.detail/2phase b/doc/TODO.detail/2phase
new file mode 100644
index 0000000000000000000000000000000000000000..aaf089007b5327599638c253e6cfceaaf3d52788
--- /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: <pgsql-hackers-owner+M49851=pgman=candle.pha.pa.us@postgresql.org>
+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 <pgman@candle.pha.pa.us>; 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 <pgsql-hackers-postgresql.org@localhost.postgresql.org>; 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 <pgsql-hackers-postgresql.org@localhost.postgresql.org>;
+ 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 <pgsql-hackers@postgresql.org>; 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 <pgsql-hackers@postgresql.org>; 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 <pgsql-hackers@postgresql.org>; 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 <pgsql-hackers@postgresql.org>; Wed Feb 4 20:22:20 2004
+X-Injected-Via-Gmane: http://gmane.org/
+To: pgsql-hackers@postgresql.org
+From: Heikki Linnakangas <hlinnaka@iki.fi>
+Subject: [HACKERS] Two-phase commit
+Date: Wed, 4 Feb 2004 22:22:16 +0200
+Lines: 30
+Message-ID: <Pine.OSF.4.58.0402042200330.238747@kosh.hut.fi>
+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: <pgsql-hackers-owner+M50166=pgman=candle.pha.pa.us@postgresql.org>
+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 <pgman@candle.pha.pa.us>; 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 <pgsql-hackers-postgresql.org@localhost.postgresql.org>; 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 <pgsql-hackers-postgresql.org@localhost.postgresql.org>;
+ 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 <pgsql-hackers@postgresql.org>; 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 <hlinnaka@iki.fi>
+X-X-Sender: hlinnaka@kosh.hut.fi
+To: "Jeroen T. Vermeulen" <jtv@xs4all.nl>
+cc: PostgreSQL Development <pgsql-hackers@postgresql.org>
+Subject: Re: [HACKERS] Two-phase commit
+In-Reply-To: <20040208195332.GE25140@xs4all.nl>
+Message-ID: <Pine.OSF.4.58.0402092201460.226205@kosh.hut.fi>
+References: <Pine.OSF.4.58.0402042200330.238747@kosh.hut.fi>
+ <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: <pgsql-hackers-owner+M49946=pgman=candle.pha.pa.us@postgresql.org>
+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 <pgman@candle.pha.pa.us>; 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 <pgsql-hackers-postgresql.org@localhost.postgresql.org>; 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 <pgsql-hackers-postgresql.org@localhost.postgresql.org>;
+ 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 <pgsql-hackers@postgresql.org>; 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" <jtv@xs4all.nl>
+To: Heikki Linnakangas <hlinnaka@iki.fi>
+cc: PostgreSQL Development <pgsql-hackers@postgresql.org>
+Subject: Re: [HACKERS] Two-phase commit
+Message-ID: <20040209205629.GB13454@xs4all.nl>
+Mail-Followup-To: Heikki Linnakangas <hlinnaka@iki.fi>,
+ PostgreSQL Development <pgsql-hackers@postgresql.org>
+References: <Pine.OSF.4.58.0402042200330.238747@kosh.hut.fi> <20040208195332.GE25140@xs4all.nl> <Pine.OSF.4.58.0402092201460.226205@kosh.hut.fi>
+MIME-Version: 1.0
+Content-Type: text/plain; charset=us-ascii
+Content-Disposition: inline
+In-Reply-To: <Pine.OSF.4.58.0402092201460.226205@kosh.hut.fi>
+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: <pgsql-hackers-owner+M50540=pgman=candle.pha.pa.us@postgresql.org>
+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 <pgman@candle.pha.pa.us>; 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 <pgsql-hackers-postgresql.org@localhost.postgresql.org>; 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 <pgsql-hackers-postgresql.org@localhost.postgresql.org>;
+ 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 <pgsql-hackers@postgresql.org>; 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 <pgsql-hackers@postgresql.org>; 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 <pgsql-hackers@postgresql.org>; 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 <pgsql-hackers@postgresql.org>; Sun Feb 22 02:27:00 2004
+X-Injected-Via-Gmane: http://gmane.org/
+To: pgsql-hackers@postgresql.org
+From: Heikki Linnakangas <hlinnaka@iki.fi>
+Subject: Re: [HACKERS] Two-phase commit
+Date: Sun, 22 Feb 2004 04:26:56 +0200
+Lines: 70
+Message-ID: <Pine.OSF.4.58.0402220324250.126984@kosh.hut.fi>
+References: <Pine.OSF.4.58.0402042200330.238747@kosh.hut.fi>
+ <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: <pgsql-general-owner+M58726=pgman=candle.pha.pa.us@postgresql.org>
+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 <pgman@candle.pha.pa.us>; 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 <pgsql-general-postgresql.org@localhost.postgresql.org>; 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 <pgsql-general-postgresql.org@localhost.postgresql.org>;
+ 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 <pgsql-general@postgresql.org>; 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 <lists@zara.6.isreserved.com>
+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 <hixson@poindextrose.org>
+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: <pgsql-hackers-owner+M51632@postgresql.org>
+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 <pgman@candle.pha.pa.us>; 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 <hlinnaka@iki.fi>
+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: <Pine.OSF.4.58.0402220324250.126984@kosh.hut.fi>
+Message-ID: <Pine.OSF.4.58.0403231758350.513267@kosh.hut.fi>
+References: <Pine.OSF.4.58.0402042200330.238747@kosh.hut.fi>
+ <200402080138.i181cPl15259@candle.pha.pa.us> <Pine.OSF.4.58.0402220324250.126984@kosh.hut.fi>
+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: <Pine.OSF.4.58.0403231810351.513267@kosh.hut.fi>
+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: <pgsql-hackers-owner+M51641@postgresql.org>
+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 <pgman@candle.pha.pa.us>; 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 <pgsql-hackers-postgresql.org@localhost.postgresql.org>; 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 <pgsql-hackers-postgresql.org@localhost.postgresql.org>;
+ 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 <pgsql-hackers@postgresql.org>; 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 <alvherre@dcc.uchile.cl>
+To: Heikki Linnakangas <hlinnaka@iki.fi>
+cc: pgsql-hackers@postgresql.org
+Subject: Re: [HACKERS] Two-phase commit
+Message-ID: <20040323182843.GF3863@dcc.uchile.cl>
+References: <Pine.OSF.4.58.0402042200330.238747@kosh.hut.fi> <200402080138.i181cPl15259@candle.pha.pa.us> <Pine.OSF.4.58.0402220324250.126984@kosh.hut.fi> <Pine.OSF.4.58.0403231758350.513267@kosh.hut.fi>
+MIME-Version: 1.0
+Content-Type: text/plain; charset=us-ascii
+Content-Disposition: inline
+In-Reply-To: <Pine.OSF.4.58.0403231758350.513267@kosh.hut.fi>
+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 (<alvherre[a]dcc.uchile.cl>)
+"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: <jtv@xs4all.nl>
+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 <pgman@candle.pha.pa.us>; 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" <jtv@xs4all.nl>
+To: pgadmin@pse-consulting.de, Bruce Momjian <pgman@candle.pha.pa.us>
+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: <pgsql-hackers-owner+M59934=pgman=candle.pha.pa.us@postgresql.org>
+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 <pgman@candle.pha.pa.us>; 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 <pgman@candle.pha.pa.us>; 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 <pgman@candle.pha.pa.us>;
+ 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 <pgman@candle.pha.pa.us>; 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 <pgsql-hackers-postgresql.org@localhost.postgresql.org>; 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 <pgsql-hackers-postgresql.org@localhost.postgresql.org>;
+ 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 <pgsql-hackers@postgresql.org>; 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 <hlinnaka@iki.fi>
+X-X-Sender: hlinnaka@kosh.hut.fi
+To: Tom Lane <tgl@sss.pgh.pa.us>
+cc: Heikki Linnakangas <hlinnaka@iki.fi>, pgsql-hackers@postgresql.org
+Subject: Re: [HACKERS] Two-phase commit
+In-Reply-To: <354.1097099170@sss.pgh.pa.us>
+Message-ID: <Pine.OSF.4.61.0410071357420.432862@kosh.hut.fi>
+References: <Pine.OSF.4.58.0402042200330.238747@kosh.hut.fi>
+ <200402080138.i181cPl15259@candle.pha.pa.us> <Pine.OSF.4.58.0402220324250.126984@kosh.hut.fi>
+ <Pine.OSF.4.58.0403231758350.513267@kosh.hut.fi> <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 <hlinnaka@iki.fi> 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: <pgsql-hackers-owner+M59924=pgman=candle.pha.pa.us@postgresql.org>
+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 <pgman@candle.pha.pa.us>; 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 <pgman@candle.pha.pa.us>; 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 <pgman@candle.pha.pa.us>;
+ 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 <pgman@candle.pha.pa.us>; 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 <pgsql-hackers-postgresql.org@localhost.postgresql.org>; 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 <pgsql-hackers-postgresql.org@localhost.postgresql.org>;
+ 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 <pgsql-hackers@postgresql.org>; 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 <pgsql-hackers@postgresql.org>; Sat, 9 Oct 2004 14:48:09 +0300
+Date: Sat, 9 Oct 2004 14:48:09 +0300 (EEST)
+From: Heikki Linnakangas <hlinnaka@iki.fi>
+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: <Pine.OSF.4.61.0410091429320.339489@kosh.hut.fi>
+References: <Pine.OSF.4.58.0402042200330.238747@kosh.hut.fi>
+ <200402080138.i181cPl15259@candle.pha.pa.us> <Pine.OSF.4.58.0402220324250.126984@kosh.hut.fi>
+ <Pine.OSF.4.58.0403231758350.513267@kosh.hut.fi> <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: <pgsql-hackers-owner+M60193=pgman=candle.pha.pa.us@postgresql.org>
+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 <pgman@candle.pha.pa.us>; 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 <pgman@candle.pha.pa.us>; 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 <pgman@candle.pha.pa.us>;
+ 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 <pgman@candle.pha.pa.us>; 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 <pgsql-hackers-postgresql.org@localhost.postgresql.org>; 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 <pgsql-hackers-postgresql.org@localhost.postgresql.org>;
+ 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 <pgsql-hackers@postgresql.org>; 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 <pgsql-hackers@postgresql.org>; 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: <OFC4281B9F.ABCA4E46-ON07256F33.0054BD37-07256F33.00562470@us-phx1.az05.bull.com>
+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: <pgsql-hackers-owner+M63326=pgman=candle.pha.pa.us@postgresql.org>
+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 <pgman@candle.pha.pa.us>; 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 <pgman@candle.pha.pa.us>; 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 <pgman@candle.pha.pa.us>;
+ 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 <pgman@candle.pha.pa.us>; 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 <pgsql-hackers-postgresql.org@localhost.postgresql.org>; 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 <pgsql-hackers-postgresql.org@localhost.postgresql.org>;
+ 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 <pgsql-hackers@postgresql.org>; 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 <pgsql-hackers@postgresql.org>; 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 <pgsql-hackers@postgresql.org>;
+ 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 <pgsql-hackers@postgresql.org>; Wed, 19 Jan 2005 20:55:57 +0200
+Date: Wed, 19 Jan 2005 20:55:57 +0200 (EET)
+From: Heikki Linnakangas <hlinnaka@iki.fi>
+X-X-Sender: hlinnaka@kosh.hut.fi
+To: pgsql-hackers@postgresql.org
+Subject: [HACKERS] Two-phase commit for 8.1
+Message-ID: <Pine.OSF.4.61.0501192055310.62540@kosh.hut.fi>
+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: <pgsql-hackers-owner+M63328=pgman=candle.pha.pa.us@postgresql.org>
+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 <pgman@candle.pha.pa.us>; 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 <pgman@candle.pha.pa.us>; 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 <pgman@candle.pha.pa.us>;
+ 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 <pgman@candle.pha.pa.us>; 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 <pgsql-hackers-postgresql.org@localhost.postgresql.org>; 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 <pgsql-hackers-postgresql.org@localhost.postgresql.org>;
+ 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 <pgsql-hackers@postgresql.org>; 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" <scrappy@postgresql.org>
+X-X-Sender: scrappy@ganymede.hub.org
+To: Heikki Linnakangas <hlinnaka@iki.fi>
+cc: pgsql-hackers@postgresql.org
+Subject: Re: [HACKERS] Two-phase commit for 8.1
+In-Reply-To: <Pine.OSF.4.61.0501192055310.62540@kosh.hut.fi>
+Message-ID: <20050119165747.U47533@ganymede.hub.org>
+References: <Pine.OSF.4.61.0501192055310.62540@kosh.hut.fi>
+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: <pgsql-hackers-owner+M63331=pgman=candle.pha.pa.us@postgresql.org>
+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 <pgman@candle.pha.pa.us>; 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 <pgman@candle.pha.pa.us>; 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 <pgman@candle.pha.pa.us>;
+ 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 <pgman@candle.pha.pa.us>; 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" <scrappy@postgresql.org>
+cc: Heikki Linnakangas <hlinnaka@iki.fi>, pgsql-hackers@postgresql.org
+Subject: Re: [HACKERS] Two-phase commit for 8.1
+In-Reply-To: <20050119165747.U47533@ganymede.hub.org>
+References: <Pine.OSF.4.61.0501192055310.62540@kosh.hut.fi> <20050119165747.U47533@ganymede.hub.org>
+Comments: In-reply-to "Marc G. Fournier" <scrappy@postgresql.org>
+ 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 <tgl@sss.pgh.pa.us>
+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" <scrappy@postgresql.org> 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: <pgsql-hackers-owner+M63432=pgman=candle.pha.pa.us@postgresql.org>
+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 <pgman@candle.pha.pa.us>; 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 <pgman@candle.pha.pa.us>; 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 <pgman@candle.pha.pa.us>;
+ 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 <pgman@candle.pha.pa.us>; 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 <pgsql-hackers-postgresql.org@localhost.postgresql.org>; 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 <pgsql-hackers-postgresql.org@localhost.postgresql.org>;
+ 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 <pgsql-hackers@postgresql.org>; 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 <hlinnaka@iki.fi>
+X-X-Sender: hlinnaka@kosh.hut.fi
+To: =?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= <postgres@cybertec.at>
+cc: pgsql-hackers@postgresql.org
+Subject: Re: [HACKERS] Two-phase commit for 8.1
+In-Reply-To: <41F3699B.2060608@cybertec.at>
+Message-ID: <Pine.OSF.4.61.0501231147320.64318@kosh.hut.fi>
+References: <Pine.OSF.4.61.0501192055310.62540@kosh.hut.fi>
+ <20050119165747.U47533@ganymede.hub.org> <1115.1106181723@sss.pgh.pa.us>
+ <Pine.OSF.4.61.0501212033520.352045@kosh.hut.fi> <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: <pgsql-hackers-owner+M63434=pgman=candle.pha.pa.us@postgresql.org>
+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 <pgman@candle.pha.pa.us>; 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 <pgman@candle.pha.pa.us>; 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 <pgman@candle.pha.pa.us>;
+ 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 <pgman@candle.pha.pa.us>; 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 <pgsql-hackers-postgresql.org@localhost.postgresql.org>; 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 <pgsql-hackers-postgresql.org@localhost.postgresql.org>;
+ 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 <pgsql-hackers@postgresql.org>; 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 <alvherre@dcc.uchile.cl>
+To: Heikki Linnakangas <hlinnaka@iki.fi>
+cc: =?iso-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= <postgres@cybertec.at>,
+ pgsql-hackers@postgresql.org
+Subject: Re: [HACKERS] Two-phase commit for 8.1
+Message-ID: <20050123151337.GD4406@dcc.uchile.cl>
+References: <Pine.OSF.4.61.0501192055310.62540@kosh.hut.fi> <20050119165747.U47533@ganymede.hub.org> <1115.1106181723@sss.pgh.pa.us> <Pine.OSF.4.61.0501212033520.352045@kosh.hut.fi> <41F3699B.2060608@cybertec.at> <Pine.OSF.4.61.0501231147320.64318@kosh.hut.fi>
+MIME-Version: 1.0
+Content-Type: text/plain; charset=us-ascii
+Content-Disposition: inline
+In-Reply-To: <Pine.OSF.4.61.0501231147320.64318@kosh.hut.fi>
+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 (<alvherre[@]dcc.uchile.cl>)
+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: <pgsql-hackers-owner+M63438=pgman=candle.pha.pa.us@postgresql.org>
+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 <pgman@candle.pha.pa.us>; 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 <pgman@candle.pha.pa.us>; 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 <pgman@candle.pha.pa.us>;
+ 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 <pgman@candle.pha.pa.us>; 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 <pgsql-hackers-postgresql.org@localhost.postgresql.org>; 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 <pgsql-hackers-postgresql.org@localhost.postgresql.org>;
+ 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 <pgsql-hackers@postgresql.org>; 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 <hlinnaka@iki.fi>
+X-X-Sender: hlinnaka@kosh.hut.fi
+To: Alvaro Herrera <alvherre@dcc.uchile.cl>
+cc: =?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= <postgres@cybertec.at>,
+ pgsql-hackers@postgresql.org
+Subject: Re: [HACKERS] Two-phase commit for 8.1
+In-Reply-To: <20050123151337.GD4406@dcc.uchile.cl>
+Message-ID: <Pine.OSF.4.61.0501231916520.414393@kosh.hut.fi>
+References: <Pine.OSF.4.61.0501192055310.62540@kosh.hut.fi>
+ <20050119165747.U47533@ganymede.hub.org> <1115.1106181723@sss.pgh.pa.us>
+ <Pine.OSF.4.61.0501212033520.352045@kosh.hut.fi> <41F3699B.2060608@cybertec.at>
+ <Pine.OSF.4.61.0501231147320.64318@kosh.hut.fi> <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: <pgsql-hackers-owner+M63788=pgman=candle.pha.pa.us@postgresql.org>
+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 <pgman@candle.pha.pa.us>; 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 <pgman@candle.pha.pa.us>; 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 <pgman@candle.pha.pa.us>;
+ 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 <pgman@candle.pha.pa.us>; 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 <pgsql-hackers-postgresql.org@localhost.postgresql.org>; 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 <pgsql-hackers-postgresql.org@localhost.postgresql.org>;
+ 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 <pgsql-hackers@postgresql.org>; 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 <alvherre@dcc.uchile.cl>
+To: Heikki Linnakangas <hlinnaka@iki.fi>
+cc: =?iso-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= <postgres@cybertec.at>,
+ pgsql-hackers@postgresql.org
+Subject: Re: [HACKERS] Two-phase commit for 8.1
+Message-ID: <20050131150119.GI22141@dcc.uchile.cl>
+References: <Pine.OSF.4.61.0501192055310.62540@kosh.hut.fi> <20050119165747.U47533@ganymede.hub.org> <1115.1106181723@sss.pgh.pa.us> <Pine.OSF.4.61.0501212033520.352045@kosh.hut.fi> <41F3699B.2060608@cybertec.at> <Pine.OSF.4.61.0501231147320.64318@kosh.hut.fi> <20050123151337.GD4406@dcc.uchile.cl> <Pine.OSF.4.61.0501231916520.414393@kosh.hut.fi>
+MIME-Version: 1.0
+Content-Type: text/plain; charset=iso-8859-1
+Content-Disposition: inline
+Content-Transfer-Encoding: 8bit
+In-Reply-To: <Pine.OSF.4.61.0501231916520.414393@kosh.hut.fi>
+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 (<alvherre[@]dcc.uchile.cl>)
+"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: <pgsql-hackers-owner+M66050@postgresql.org>
+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 <pgman@candle.pha.pa.us>; 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 <pgman@candle.pha.pa.us>; 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 <pgman@candle.pha.pa.us>;
+ 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 <pgman@candle.pha.pa.us>; 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 <pgsql-hackers-postgresql.org@localhost.postgresql.org>; 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 <pgsql-hackers-postgresql.org@localhost.postgresql.org>;
+ 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 <pgsql-hackers@postgresql.org>; 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 <hlinnaka@iki.fi>
+X-X-Sender: hlinnaka@kosh.hut.fi
+To: Alvaro Herrera <alvherre@dcc.uchile.cl>
+cc: pgsql-hackers@postgresql.org
+Subject: Re: [HACKERS] Two phase commit
+In-Reply-To: <20050405230731.GA26960@surnet.cl>
+Message-ID: <Pine.OSF.4.61.0504061652300.502110@kosh.hut.fi>
+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 0000000000000000000000000000000000000000..d4d4c4140477f4d7dbcac938f86ca84be51287dd
--- /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: <pgsql-admin-owner+M15281=pgman=candle.pha.pa.us@postgresql.org>
+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 <pgman@candle.pha.pa.us>; 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 <pgman@candle.pha.pa.us>; 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 <pgman@candle.pha.pa.us>;
+ 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 <pgman@candle.pha.pa.us>; 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 <pgsql-admin-postgresql.org@localhost.postgresql.org>; 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 <pgsql-admin-postgresql.org@localhost.postgresql.org>;
+ 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 <pgsql-admin@postgresql.org>; 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 <pgsql-admin@postgresql.org>; 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 <mendola@bigfoot.com>
+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 <xzilla@users.sourceforge.net>
+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 <PID> /mnt/server/partialdir <pg_xlog path>
+
+~ 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: <pgsql-admin-owner+M15295=pgman=candle.pha.pa.us@postgresql.org>
+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 <pgman@candle.pha.pa.us>; 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 <pgman@candle.pha.pa.us>; 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 <pgman@candle.pha.pa.us>;
+ 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 <pgman@candle.pha.pa.us>; 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 <pgsql-admin-postgresql.org@localhost.postgresql.org>; 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 <pgsql-admin-postgresql.org@localhost.postgresql.org>;
+ 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 <pgsql-admin@postgresql.org>; 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" <simon@2ndquadrant.com>
+To: "Gaetano Mendola" <mendola@bigfoot.com>,
+ "Robert Treat" <xzilla@users.sourceforge.net>, <pgsql-admin@postgresql.org>
+cc: <iain@mst.co.jp>
+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: <pgsql-admin-owner+M15302=pgman=candle.pha.pa.us@postgresql.org>
+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 <pgman@candle.pha.pa.us>; 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 <pgman@candle.pha.pa.us>; 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 <pgman@candle.pha.pa.us>;
+ 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 <pgman@candle.pha.pa.us>; 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 <pgsql-admin-postgresql.org@localhost.postgresql.org>; 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 <pgsql-admin-postgresql.org@localhost.postgresql.org>;
+ 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 <pgsql-admin@postgresql.org>; 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 <mendola@bigfoot.com>
+User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
+X-Accept-Language: en-us, en
+MIME-Version: 1.0
+To: Simon Riggs <simon@2ndquadrant.com>
+cc: Robert Treat <xzilla@users.sourceforge.net>, 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: <pgsql-admin-owner+M15303=pgman=candle.pha.pa.us@postgresql.org>
+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 <pgman@candle.pha.pa.us>; 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 <pgman@candle.pha.pa.us>; 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 <pgman@candle.pha.pa.us>;
+ 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 <pgman@candle.pha.pa.us>; 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 <pgsql-admin-postgresql.org@localhost.postgresql.org>; 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 <pgsql-admin-postgresql.org@localhost.postgresql.org>;
+ 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 <pgsql-admin@postgresql.org>; 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 <simon@2ndquadrant.com>
+To: Gaetano Mendola <mendola@bigfoot.com>
+cc: Robert Treat <xzilla@users.sourceforge.net>, 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: <pgsql-admin-owner+M15306=pgman=candle.pha.pa.us@postgresql.org>
+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 <pgman@candle.pha.pa.us>; 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 <pgman@candle.pha.pa.us>; 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 <pgman@candle.pha.pa.us>;
+ 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 <pgman@candle.pha.pa.us>; 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 <pgsql-admin-postgresql.org@localhost.postgresql.org>; 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 <pgsql-admin-postgresql.org@localhost.postgresql.org>;
+ 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 <pgsql-admin@postgresql.org>; 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 <pgsql-admin@postgresql.org>; 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 <mendola@bigfoot.com>
+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 <simon@2ndquadrant.com>
+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
+