Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id C69591337BEE for ; Fri, 18 Mar 2011 13:49:14 -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 65790-03 for ; Fri, 18 Mar 2011 16:49:04 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from gw.wicourts.gov (gwmta.wicourts.gov [165.219.244.99]) by mail.postgresql.org (Postfix) with ESMTP id 1B0A31337BE7 for ; Fri, 18 Mar 2011 13:49:03 -0300 (ADT) Received: from Courts-MTA by gw.wicourts.gov with Novell_GroupWise; Fri, 18 Mar 2011 11:49:03 -0500 Message-Id: <4D8346A9020000250003BAC3@gw.wicourts.gov> X-Mailer: Novell GroupWise Internet Agent 8.0.1 Date: Fri, 18 Mar 2011 11:48:57 -0500 From: "Kevin Grittner" To: "Simon Riggs" , "Robert Haas" Cc: "Markus Wanner" , "Alvaro Herrera" , "Andrew Dunstan" , "Heikki Linnakangas" , "MARK CALLAGHAN" , "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> <4D837EA2.2070205@enterprisedb.com> <1300465171.18619.15193.camel@ebony> In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline 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/1151 X-Sequence-Number: 184401 Robert Haas wrote: > Simon Riggs wrote: >> No, only in the case where you choose not to failover to the >> standby when you crash, which would be a fairly strange choice >> after the effort to set up the standby. In a correctly configured >> and operated cluster what I say above is fully correct and needs >> no addendum. > what do you do if a meteor hits the synchronous standby and at the > same time you lose power to the master? No amount of > configuration will save you from coming back on line with a > visible-but-unreplicated transaction. You don't even need to postulate an extreme condition like that; we prefer to have a DBA pull the trigger on a failover, rather than trust the STONITH call to software. This is particularly true when the master is local to its primary users and the replica is remote to them. -Kevin