Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id 115791337BF6 for ; Fri, 18 Mar 2011 04:52:26 -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 07726-08 for ; Fri, 18 Mar 2011 07:52:15 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail148113.authsmtp.com (outmail148113.authsmtp.com [62.13.148.113]) by mail.postgresql.org (Postfix) with ESMTP id 85D7E1337B43 for ; Fri, 18 Mar 2011 04:52:14 -0300 (ADT) Received: from mail-c193.authsmtp.com (mail-c193.authsmtp.com [62.13.128.118]) by punt10.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id p2I7qB60078182; Fri, 18 Mar 2011 07:52:11 GMT Received: from [192.168.0.3] ([81.5.146.37]) (authenticated bits=0) by mail.authsmtp.com (8.14.2/8.14.2) with ESMTP id p2I7q7pp076276; Fri, 18 Mar 2011 07:52:08 GMT Subject: Re: [COMMITTERS] pgsql: Efficient transaction-controlled synchronous replication. From: Simon Riggs To: Fujii Masao Cc: Robert Haas , PostgreSQL-development In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Fri, 18 Mar 2011 07:52:07 +0000 Message-ID: <1300434727.18619.10231.camel@ebony> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit X-Server-Quench: 9fe972c8-5134-11e0-97bb-002264978518 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCdxZQATClZOTQEd DAteCiN5VAwpPBRK HVkIKg5MJUcNSQVJ NksadRtFaQ1bYFhD HGQLWlVEUFp7XGF/ awIfZQRDZ1RPWwN0 U09WR1pVCwUmQR54 AV8ZEllycANEf3g+ bUFgWT5SChFzckQu SlNRFG4CeGZhPWAC WUcKJR5UcAFIeBtM bVh6VXtDAzANdhEY NiQQEgoKCH1sAwNw ZyAxEX8oenNDBjEn XhRQVRghE0wORig1 M1Q6MFcaB08aLkQ1 Nx4qXlQEKRgWDgBS fQlWESlSJ0MGQS02 FktAUFYaETZUXSZb BFtA X-Authentic-SMTP: 61633235383639.1014: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=2.419 tagged_above=-5 required=5 tests=BAYES_00=-1.9, FS_REPLICA=3.599, SARE_SPEC_REPLICA=0.72 X-Spam-Level: ** X-Archive-Number: 201103/1101 X-Sequence-Number: 184351 On Fri, 2011-03-18 at 14:45 +0900, Fujii Masao wrote: > On Fri, Mar 18, 2011 at 2:52 AM, Robert Haas wrote: > > On Thu, Mar 10, 2011 at 3:04 PM, Robert Haas wrote: > >>> - /* Let the master know that we received some data. */ > >>> - XLogWalRcvSendReply(); > >>> - XLogWalRcvSendHSFeedback(); > >>> > >>> This change completely eliminates the difference between write_location > >>> and flush_location in pg_stat_replication. If this change is reasoable, we > >>> should get rid of write_location from pg_stat_replication since it's useless. > >>> If not, this change should be reverted. I'm not sure whether monitoring > >>> the difference between write and flush locations is useful. But I guess that > >>> someone thought so and that code was added. > >> > >> I could go either way on this but clearly we need to do one or the other. > > > > I'm not really sure why this was part of the synchronous replication > > patch, but after mulling it over I think it's probably right to rip > > out write_location completely. There shouldn't ordinarily be much of > > a gap between write location and flush location, so it's probably not > > worth the extra network overhead to keep track of it. We might need > > to re-add some form of this in the future if we have a version of > > synchronous replication that only waits for confirmation of receipt > > rather than for confirmation of flush, but we don't have that in 9.1, > > so why bother? > > > > Barring objections, I'll go do that. > > I agree to get rid of write_location. No, don't remove it. We seem to be just looking for things to tweak without any purpose. Removing this adds nothing for us. We will have the column in the future, it is there now, so leave it. -- Simon Riggs http://www.2ndQuadrant.com/books/ PostgreSQL Development, 24x7 Support, Training and Services