Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id 41773133655C for ; Fri, 18 Mar 2011 11:37:39 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.251]) (amavisd-maia, port 10024) with ESMTP id 05483-03 for ; Fri, 18 Mar 2011 14:37:32 +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 E0779133616B for ; Fri, 18 Mar 2011 11:37:31 -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 15:37:26 +0100 id 0000000002A08005.000000004D836E2B.00005CF9 Message-ID: <4D836E26.6080503@bluegap.ch> Date: Fri, 18 Mar 2011 15:37:26 +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: MARK CALLAGHAN , Simon Riggs , 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> <4D831A76020000250003BA82@gw.wicourts.gov> In-Reply-To: <4D831A76020000250003BA82@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/1130 X-Sequence-Number: 184380 Hi, On 03/18/2011 02:40 PM, Kevin Grittner wrote: > Then the only thing you would consider sync replication, as far as I > can see, is two phase commit I think waiting for the ACK before actually making the changes from the transaction visible (COMMIT) would suffice for disallowing such an inconsistency to manifest. But obviously, MySQL decided it's not worth doing that, as it's such a rare event and a short period of time that may show inconsistencies... > people's needs. The guarantee that some people are looking for is > that a successful commit means that the data has been persisted on > two separate servers. Well, MySQL's semi-sync also seems to guarantee that WRT the client confirmation. And transactions always appear committed *before* the client receives the COMMIT acknowledgement, due to the time it takes for the ACK to arrive at the client. It's just the commit *before* receiving the slave's ACK, which might make a transaction visible that's not durable, yet. But I guess that simplified implementation for them... Regards Markus Wanner