Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id AD9501337B64 for ; Tue, 4 Jan 2011 22:00:35 -0400 (AST) 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 92694-05 for ; Wed, 5 Jan 2011 02:00:27 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by mail.postgresql.org (Postfix) with ESMTP id 5BCB41337B4A for ; Tue, 4 Jan 2011 22:00:27 -0400 (AST) Received: from [192.168.1.6] (mail.highperformancepostgresql.com [71.179.240.8]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis) id 0Lpgco-1QEIZs40Ri-00fQBo; Wed, 05 Jan 2011 03:00:00 +0100 Message-ID: <4D23D09D.3000207@2ndquadrant.com> Date: Tue, 04 Jan 2011 20:59:57 -0500 From: Greg Smith User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: Simon Riggs CC: Josh Berkus , Heikki Linnakangas , Robert Haas , Hannu Krosing , Stefan Kaltenbrunner , pgsql-hackers@postgresql.org Subject: Re: Sync Rep Design References: <1293729972.1892.23804.camel@ebony> <4D1CC47E.7050207@kaltenbrunner.cc> <1293735853.1892.24886.camel@ebony> <4D1D8B2F.5070001@2ndquadrant.com> <4D1DAB14.5000800@enterprisedb.com> <1293796137.1892.37313.camel@ebony> <4D1DCF5A.7070808@enterprisedb.com> <4D1E4897.1050400@2ndquadrant.com> <1293882875.1892.56143.camel@ebony> <1293975673.2090.464.camel@ebony> <4D20ADC5.7070804@enterprisedb.com> <1294003186.2090.3338.camel@ebony> <4D2366CE.1010705@agliodbs.com> <1294167105.19612.8276.camel@ebony> In-Reply-To: <1294167105.19612.8276.camel@ebony> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:z/yUMjByuziUjaGOwPV9HGLwxEss4tg3mWmKEf9JWGq OtuRkRbMicT7A0/7hDL3gt9ETgAOQ56IXjD4Uk7TN14ImDMPj1 FprBHplevXJXecLKu3EXL121lJtujOB7OvMcLroFp/PLuRmUCv Fe8LjIG49PPnEMqwga+MLe8YCIRrlEgG00TmPIJiFUH5PvTfur 0UxOBXOsPu5ZiZgVRO4DAN5vMLbSYx47R2mXcu3yN0= X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.9 tagged_above=-5 required=5 tests=BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001 X-Spam-Level: X-Archive-Number: 201101/297 X-Sequence-Number: 178134 Simon Riggs wrote: > Based upon that series of conversations, I've reworked the design so > that there is (currently) only a single standby offering sync rep at any > one time. Other standbys can request to be sync standbys but they only > become the sync standby if the first one fails. Which was simple to do > and bridges the challenges of an exactly identified sync standby and the > fragility of too closely specifying the config. > That seems like a good enough starting point to cover a lot of cases. Presuming the two servers each at two sites config that shows up in a lot of these discussions, people in the "I need sync to a remote spot" can get that, and if that site is unavailable for long enough to be kicked out they'll smoothly degrade to sync on a secondary local copy. And those who want high performance local sync and best-effort for the remote site can configure for that too, and if the local secondary dies they'll just degrade to the slow remote commits. -- Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD PostgreSQL Training, Services and Support www.2ndQuadrant.us "PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books