Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id 54F3C1337B7E for ; Wed, 16 Feb 2011 12:32:38 -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 34100-10 for ; Wed, 16 Feb 2011 16:32:31 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail149101.authsmtp.com (outmail149101.authsmtp.com [62.13.149.101]) by mail.postgresql.org (Postfix) with ESMTP id 89E9A1337B68 for ; Wed, 16 Feb 2011 12:32:29 -0400 (AST) Received: from mail-c194.authsmtp.com (mail-c194.authsmtp.com [62.13.128.121]) by punt5.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id p1GGWOKd056850; Wed, 16 Feb 2011 16:32:24 GMT Received: from [192.168.0.4] ([81.5.146.37]) (authenticated bits=0) by mail.authsmtp.com (8.14.2/8.14.2) with ESMTP id p1GGWMS2077779; Wed, 16 Feb 2011 16:32:22 GMT Subject: Re: Sync Rep for 2011CF1 From: Simon Riggs To: Heikki Linnakangas Cc: Robert Haas , Fujii Masao , pgsql-hackers@postgresql.org In-Reply-To: <4D5BEFF9.6020906@enterprisedb.com> References: <1295127631.3282.100.camel@ebony> <4D543723.9050101@enterprisedb.com> <1297870600.1747.30144.camel@ebony> <4D5BEFF9.6020906@enterprisedb.com> Content-Type: text/plain; charset="UTF-8" Date: Wed, 16 Feb 2011 16:32:21 +0000 Message-ID: <1297873941.1747.30561.camel@ebony> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit X-Server-Quench: 54b87975-39ea-11e0-80b9-0022640b883e X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCdxZQATClZOTQEd DAteCiN5VAwpPBRK HVkIKg5MJUcNSQVJ NksachtFaQNba1xT HGQLWlVEUVt7WmF/ aQgfZQRDZ1RPWwN0 U09WR1pVCwUmQR12 cXljMRtycAJBf3c+ bEZrWD5eWBZyck96 R1NXHDhXeGZhPWAC WEAKfh5UcAFIeBtF OFh3VyZDAzANdhEY NiQQEgoKCH1kOSJe CjsANRocRlxDRGZl HjssRF1/ 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, RCVD_IN_DNSWL_NONE=-0.0001 X-Spam-Level: X-Archive-Number: 201102/1536 X-Sequence-Number: 182325 On Wed, 2011-02-16 at 17:40 +0200, Heikki Linnakangas wrote: > On 16.02.2011 17:36, Simon Riggs wrote: > > On Tue, 2011-02-15 at 12:08 -0500, Robert Haas wrote: > >> On Mon, Feb 14, 2011 at 12:25 AM, Fujii Masao wrote: > >>> On Fri, Feb 11, 2011 at 4:06 AM, Heikki Linnakangas > >>> wrote: > >>>> I added a XLogWalRcvSendReply() call into XLogWalRcvFlush() so that it also > >>>> sends a status update every time the WAL is flushed. If the walreceiver is > >>>> busy receiving and flushing, that would happen once per WAL segment, which > >>>> seems sensible. > >>> > >>> This change can make the callback function "WalRcvDie()" call ereport(ERROR) > >>> via XLogWalRcvFlush(). This looks unsafe. > >> > >> Good catch. Is the cleanest solution to pass a boolean parameter to > >> XLogWalRcvFlush() indicating whether we're in the midst of dying? > > > > Surely if you do this then sync rep will fail to respond correctly if > > WalReceiver dies. > > > > Why is it OK to write to disk, but not OK to reply? > > Because the connection might be dead. A broken connection is a likely > cause of walreceiver death. Would it not be possible to check that? -- Simon Riggs http://www.2ndQuadrant.com/books/ PostgreSQL Development, 24x7 Support, Training and Services