Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id 182A41337B5D for ; Fri, 31 Dec 2010 06:26:31 -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 09329-06 for ; Fri, 31 Dec 2010 10:26:24 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail148154.authsmtp.co.uk (outmail148154.authsmtp.co.uk [62.13.148.154]) by mail.postgresql.org (Postfix) with ESMTP id D6A3E1337B50 for ; Fri, 31 Dec 2010 06:26:22 -0400 (AST) Received: from mail-c194.authsmtp.com (mail-c194.authsmtp.com [62.13.128.121]) by punt6.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id oBVAQIw4039003; Fri, 31 Dec 2010 10:26:18 GMT Received: from [192.168.0.2] ([81.5.146.37]) (authenticated bits=0) by mail.authsmtp.com (8.14.2/8.14.2) with ESMTP id oBVAQGg6027958; Fri, 31 Dec 2010 10:26:16 GMT Subject: Re: Sync Rep Design From: Simon Riggs To: Stefan Kaltenbrunner Cc: pgsql-hackers@postgresql.org In-Reply-To: <4D1D93F1.80602@kaltenbrunner.cc> References: <1293729972.1892.23804.camel@ebony> <4D1CC47E.7050207@kaltenbrunner.cc> <1293735853.1892.24886.camel@ebony> <4D1CEEAF.8050209@kaltenbrunner.cc> <1293744235.1892.26478.camel@ebony> <4D1D93F1.80602@kaltenbrunner.cc> Content-Type: text/plain; charset="UTF-8" Date: Fri, 31 Dec 2010 10:26:11 +0000 Message-ID: <1293791171.1892.36233.camel@ebony> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit X-Server-Quench: 666b6e21-14c8-11e0-80b9-0022640b883e X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCdxZQATClZOTQEd DAteCiN5VAwpPBRK HVkIKg5MJUcNSQVJ NksadBtFawRbaVxS HGQLWlREUV17W2V/ agwfZQRDZ1RPWwN0 U09WR1pVCwUmXm5n d39pBR9ydQJPfXY+ YUFjVj5dWkIocxN/ Q1NVET4OeGZhPWAC WEAKfh5UcAFIeBtF OFh3VyZDAzANdhEY NiQQEgoKCH1kOSJe CjsANRo+TF0KEThU X-Authentic-SMTP: 61633235383639.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/2540 X-Sequence-Number: 177802 On Fri, 2010-12-31 at 09:27 +0100, Stefan Kaltenbrunner wrote: > Maybe it has been discussed but I still don't see way it makes any > sense. If I declare a standby a sync standby I better want it sync - not > "maybe sync". consider the case of a 1 master and two identical sync > standbys - one sync standby is in the same datacenter the other is in a > backup location say 15km away. > Given there is a small constant latency to the second box (even if you > have fast networks) the end effect is that the second standby will NEVER > be sync (because the local one will always be faster) and you end up > with an async slave that cannot be used per your business rules? Your picture above is a common misconception. I will add something to the docs to explain this. 1. "sync" is a guarantee about how we respond to the client when we commit. If we wait for more than one response that slows things down, makes the cluster more fragile, complicates the code and doesn't appreciably improve the guarantee. 2. "sync" does not guarantee that the updates to the standbys are in any way coordinated. You can run a query on one standby and get one answer and at the exact same time run the same query on another standby and get a different answer (slightly ahead/behind). That also means that if the master crashes one of the servers will be ahead or behind. You can use pg_last_xlog_receive_location() to check which one that is. When people say they want *all* servers to respond, its usually because they want (2), but that is literally impossible in a distributed system. -- Simon Riggs http://www.2ndQuadrant.com/books/ PostgreSQL Development, 24x7 Support, Training and Services