Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id 7EF801337B81 for ; Fri, 18 Mar 2011 12:44:06 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.29]) (amavisd-maia, port 10024) with ESMTP id 45376-01 for ; Fri, 18 Mar 2011 15:43:56 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from shaykin.bluegap.ch (shaykin.bluegap.ch [78.46.81.73]) by mail.postgresql.org (Postfix) with ESMTP id 60B02133655C for ; Fri, 18 Mar 2011 12:43:55 -0300 (ADT) Received: from [IPv6:2001:1620:f70:16:216:e6ff:fed5:fc9] ([2001:1620:f70:16:216:e6ff:fed5:fc9]) (AUTH: LOGIN markus@bluegap.ch, TLS: TLSv1/SSLv3,256bits,AES256-SHA) by shaykin.bluegap.ch with esmtp; Fri, 18 Mar 2011 16:43:46 +0100 id 0000000002A08009.000000004D837DB3.0000654C Message-ID: <4D837DAA.4000402@bluegap.ch> Date: Fri, 18 Mar 2011 16:43:38 +0100 From: Markus Wanner User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20101226 Icedove/3.0.11 MIME-Version: 1.0 To: Kevin Grittner CC: Simon Riggs , MARK CALLAGHAN , Alvaro Herrera , Andrew Dunstan , Heikki Linnakangas , Aidan Van Dyk , pgsql-hackers Subject: Re: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication. References: <4D741441.2090704@dunslane.net> <1299454125.1696.6138.camel@ebony> <4D74896C.5030402@enterprisedb.com> <4D74DDFA.70800@dunslane.net> <4D74E584.7080409@enterprisedb.com> <4D74E9FA.7070202@dunslane.net> <4D74F3AE.9000802@dunslane.net> <4D74FDEC.5040406@enterprisedb.com> <4D74FF15.1070804@dunslane.net> <1299513979-sup-1987@alvh.no-ip.org> <4D832571.5030808@bluegap.ch> <1300457958.18619.13780.camel@ebony> <4D832B4D020000250003BA98@gw.wicourts.gov> In-Reply-To: <4D832B4D020000250003BA98@gw.wicourts.gov> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=2.409 tagged_above=-5 required=5 tests=BAYES_00=-1.9, FS_REPLICA=3.599, SARE_SPEC_REPLICA=0.72, T_RP_MATCHES_RCVD=-0.01 X-Spam-Level: ** X-Archive-Number: 201103/1140 X-Sequence-Number: 184390 On 03/18/2011 03:52 PM, Kevin Grittner wrote: > Really? I hadn't picked up on that. That makes for a lot of > complication on crash-and-recovery of a master What complication do you have in mind here? I think of it the opposite way (at least for Postgres, that is): committing a transaction that's not acknowledged means having to revert a (locally only) committed transaction if you want to use the current data to recover to some cluster-agreed state. (Of course, you can always simply transfer the whole If you don't commit the transaction before the ACK in the first place, you don't have anything special to do upon recovery. Regards Markus Wanner