Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id C7CDD1337BA4 for ; Wed, 16 Feb 2011 11:36:55 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.251]) (amavisd-maia, port 10024) with ESMTP id 54015-07 for ; Wed, 16 Feb 2011 15:36:48 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail149080.authsmtp.com (outmail149080.authsmtp.com [62.13.149.80]) by mail.postgresql.org (Postfix) with ESMTP id 11CA41337BA3 for ; Wed, 16 Feb 2011 11:36:47 -0400 (AST) Received: from mail-c187.authsmtp.com (mail-c187.authsmtp.com [62.13.128.33]) by punt10.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id p1GFaiCb080296; Wed, 16 Feb 2011 15:36:44 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 p1GFafUB004561; Wed, 16 Feb 2011 15:36:41 GMT Subject: Re: Sync Rep for 2011CF1 From: Simon Riggs To: Robert Haas Cc: Fujii Masao , Heikki Linnakangas , pgsql-hackers@postgresql.org In-Reply-To: References: <1295127631.3282.100.camel@ebony> <4D543723.9050101@enterprisedb.com> Content-Type: text/plain; charset="UTF-8" Date: Wed, 16 Feb 2011 15:36:40 +0000 Message-ID: <1297870600.1747.30144.camel@ebony> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit X-Server-Quench: 8d405341-39e2-11e0-ab46-001185d377ca X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCdxZQATClZOTQEd DAteCiN5VAwpPBRK HVkIKg5MJUcNSQVJ NksachtFaQNba1xT HGQLWlVEUVh7WmV/ bwsfZQRDZ1RPWwN0 U09WR1pVCwUmQR12 cE9IN2tydwFDfn8+ YkBqVj5TCEB6cEV5 Q1NXHDgEeGZhPWAC ARJccR5UcAJLdhoR aVd4ByJDAzANdhEY NiQQEgoKCH1kOSJe CjsANRocRlxDRGZl HjssRF0A X-Authentic-SMTP: 61633235383639.1000: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/1526 X-Sequence-Number: 182315 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? -- Simon Riggs http://www.2ndQuadrant.com/books/ PostgreSQL Development, 24x7 Support, Training and Services