Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id E87CC1337BD3 for ; Fri, 18 Mar 2011 11:20:17 -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 19444-05-3 for ; Fri, 18 Mar 2011 14:20:09 +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 511A61337BF6 for ; Fri, 18 Mar 2011 11:19:56 -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:19:56 +0100 id 0000000002A08005.000000004D836A0C.00005A2C Message-ID: <4D836A0C.3000306@bluegap.ch> Date: Fri, 18 Mar 2011 15:19:56 +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: MARK CALLAGHAN CC: Alvaro Herrera , Andrew Dunstan , Heikki Linnakangas , Aidan Van Dyk , Simon Riggs , 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> In-Reply-To: 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/1125 X-Sequence-Number: 184375 Mark, On 03/18/2011 02:16 PM, MARK CALLAGHAN wrote: > We didn't invent the term, we just implemented something that Heikki > Tuuri briefly described, for example: > http://bugs.mysql.com/bug.php?id=7440 Oh, okay, good to know who to blame ;-) However, I didn't mean to offend anybody. > I do not think this sequence should be possible in a sync replication > system. But it is possible in what has been implemented for MySQL. > Thus it was named semi-sync rather than sync. Sure? Their documentation [1] isn't entirely clear on that first: "the master blocks after the commit is done and waits until at least one semisynchronous slave acknowledges that it has received all events for the transaction" and the "slave acknowledges receipt of a transaction's events only after the events have been written to its relay log and flushed to disk". But then continues to say that "[the master is] waiting for acknowledgment from a slave after having performed a commit", so this indeed sounds like the transaction is visible to other sessions before the slave ACKs. So, semi-sync may show temporary inconsistencies in case of a master failure. Wow! Regards Markus Wanner [1] MySQL 5.5 reference manual, 17.3.8. Semisynchronous Replication: http://dev.mysql.com/doc/refman/5.5/en/replication-semisync.html