Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id 701881337B69 for ; Fri, 18 Mar 2011 06:27:22 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia, port 10024) with ESMTP id 24360-07 for ; Fri, 18 Mar 2011 09:27:15 +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 1BA0B1337B49 for ; Fri, 18 Mar 2011 06:27:14 -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 10:27:13 +0100 id 0000000002A08009.000000004D832571.000024A2 Message-ID: <4D832571.5030808@bluegap.ch> Date: Fri, 18 Mar 2011 10:27:13 +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: Alvaro Herrera CC: 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> In-Reply-To: <1299513979-sup-1987@alvh.no-ip.org> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 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/1103 X-Sequence-Number: 184353 Hi, sorry for being late to join that bike-shedding discussion. On 03/07/2011 05:09 PM, Alvaro Herrera wrote: > I think these terms are used inconsistenly enough across the industry > that what would make the most sense would be to use the common term and > document accurately what we mean by it, rather than relying on some > external entity's definition, which could change (like wikipedia's). I absolutely agree to Alvaro here. The Wikipedia definition seems to only speak about one local and one remote node. Requiring an ack from "at least one" remote node seems to cover that. Not even Wikipedia goes further in their definition and tries to explain what 'synchronous replication' could mean in case we have more than two nodes. A somewhat common expectation is, that all nodes would have to ack. However, with such a requirement a single node failure brings your cluster to a full stop. So this isn't a practical option. Google invented the term "semi-syncronous" for something that's essentially the same that we have, now, I think. However, I full heartedly hate that term (based on the reasoning that there's no semi-pregnant, either). Others (like me) use "synchronous" or (lately rather) "eager" to mean that only a majority of nodes need to send an ACK. I have to explain what I mean every time. In the end, I don't have a strong opinion either way, anymore. I'm happy to think of the replication between the master and the one standby that's sending an ACK first as "synchronous". (Even if those may well be different standbies for different transactions). Hope to have brought some light into this discussion. Regards Markus Wanner