Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id 362011337B50 for ; Fri, 31 Dec 2010 20:36:37 -0400 (AST) 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 67918-07 for ; Sat, 1 Jan 2011 00:36:31 +0000 (UTC) X-Greylist: delayed 00:15:06.725948 by SQLgrey-1.7.6 Received: from outmail149085.authsmtp.co.uk (outmail149085.authsmtp.co.uk [62.13.149.85]) by mail.postgresql.org (Postfix) with ESMTP id 748201337B4E for ; Fri, 31 Dec 2010 20:36:29 -0400 (AST) Received: from mail-c194.authsmtp.com (mail-c194.authsmtp.com [62.13.128.121]) by punt9.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id p010L7wI053869; Sat, 1 Jan 2011 00:21:07 GMT Received: from Sidney-Stratton.local (or-67-232-70-91.dhcp.embarqhsd.net [67.232.70.91]) (authenticated bits=0) by mail.authsmtp.com (8.14.2/8.14.2) with ESMTP id p010L2Ha063430; Sat, 1 Jan 2011 00:21:03 GMT Message-ID: <4D1E7366.1020607@postgresql.org> Date: Fri, 31 Dec 2010 16:20:54 -0800 From: Josh Berkus User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090223 Thunderbird/3.0b2 MIME-Version: 1.0 To: Robert Haas CC: Simon Riggs , Heikki Linnakangas , greg@2ndquadrant.com, 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> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Server-Quench: 05ef3039-153d-11e0-80b9-0022640b883e X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCdyZgscClZXSx8a IjsDFzNPUwg+PxkK BgUMOw5HJEYITQBc chkbOAIKd38VQxYD A2cKS1RUWl9wU2Nw JQxWcwdeYFRJXxtj UVdLR1BXCwUmQRwA BmIcKkhycQZCe34+ Z0ZnVncVXEEvI0V9 QUdJFGgFMXphaTUf TUhYJQpJcANIfBlB agJ3XHBYLwdSbGoL PyYYHB0LBgAXEzVT SUk3IEpabUsQHzE6 L9OY X-Authentic-SMTP: 61633136333939.1015:706 X-AuthFastPath: 0 (Was 255) X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. 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 X-Spam-Level: X-Archive-Number: 201012/2574 X-Sequence-Number: 177836 On 12/31/10 4:40 AM, Robert Haas wrote: > Someone may have proposed this before, but one way of getting standby > naming "for free" would be to make the standby names the same as the > roles used to log in, rather than adding a separate parameter. We > could just recommend to people that they use a separate, descriptive > role name for each standby. Then the synchronous_standbys parameter - > when added - would mean "a standby from one of these roles". I like this idea; it has an elegant simplicity about it and right now I can't think of any real faults. It would have the added benefit that each standby "group" would show up by the group name in ps and on pg_stat_activity. However, I agree strongly with Simon that we really want the simplest possible synch rep implementation for 9.1, given that we're currently 15 days away from the *last* commitfest. Nobody, at this point, has really even test any of the sync rep patches for reliability or performance. Here's how I could see us developing: Simplest (9.1): -- synch/async capability set on the standby in recovery.conf -- synch/async transaction status (async, recv, fsync, apply) declared as a userset by the executing session (from Simon's patch) -- only one ack for sync, regardless of the number of standbys This would allow users to have a single sync standby plus a pool of async standbys, which is what I think 90% of users who care about sync standby want. More Complex (9.2): -- all of the above, *plus* the ability to have standbys with ROLEs and require acks from one server in each ROLE. "Web-Scale" (9.3): -- all of the above, plus "group commit", the ability to specific a number of servers in each ROLE who must ack. ... but the most important thing is to make the feature for 9.1 simple, simple, simple. We know we won't get it right on the first try. --Josh Berkus