Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id C63591337BDB for ; Wed, 16 Feb 2011 11:40:55 -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 16284-03 for ; Wed, 16 Feb 2011 15:40:50 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by mail.postgresql.org (Postfix) with ESMTP id F3FA91337BAE for ; Wed, 16 Feb 2011 11:40:45 -0400 (AST) Received: from source ([74.125.82.177]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKTVvv/XjrYKoPJI/JENs/jT4IvP8MYrHW@postini.com; Wed, 16 Feb 2011 07:40:47 PST Received: by mail-wy0-f177.google.com with SMTP id 22so1376723wyf.36 for ; Wed, 16 Feb 2011 07:40:45 -0800 (PST) Received: by 10.216.51.208 with SMTP id b58mr653472wec.8.1297870845225; Wed, 16 Feb 2011 07:40:45 -0800 (PST) Received: from [192.168.1.183] (dsl-hkibrasgw2-ff7ac300-240.dhcp.inet.fi [88.195.122.240]) by mx.google.com with ESMTPS id n11sm125011wej.43.2011.02.16.07.40.42 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 16 Feb 2011 07:40:43 -0800 (PST) Message-ID: <4D5BEFF9.6020906@enterprisedb.com> Date: Wed, 16 Feb 2011 17:40:41 +0200 From: Heikki Linnakangas User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; fi-FI; rv:1.9.1.16) Gecko/20101226 Icedove/3.0.11 MIME-Version: 1.0 To: Simon Riggs CC: Robert Haas , Fujii Masao , pgsql-hackers@postgresql.org Subject: Re: Sync Rep for 2011CF1 References: <1295127631.3282.100.camel@ebony> <4D543723.9050101@enterprisedb.com> <1297870600.1747.30144.camel@ebony> In-Reply-To: <1297870600.1747.30144.camel@ebony> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-4.2 tagged_above=-5 required=5 tests=BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3 X-Spam-Level: X-Archive-Number: 201102/1529 X-Sequence-Number: 182318 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. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com