Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id 719721337BE1 for ; Wed, 11 May 2011 08:53:55 -0300 (ADT) 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 31717-02 for ; Wed, 11 May 2011 11:53:48 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by mail.postgresql.org (Postfix) with ESMTP id 5E51A133740B for ; Wed, 11 May 2011 08:53:47 -0300 (ADT) Received: from mail-ey0-f180.google.com ([209.85.215.180]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKTcp4yX9VTqWqOk+g1YqA0WiCVzyBRH4y@postini.com; Wed, 11 May 2011 04:53:48 PDT Received: by eyg24 with SMTP id 24so156188eyg.11 for ; Wed, 11 May 2011 04:53:44 -0700 (PDT) Received: by 10.213.112.198 with SMTP id x6mr3348817ebp.61.1305114824440; Wed, 11 May 2011 04:53:44 -0700 (PDT) Received: from [192.168.1.183] (dsl-hkibrasgw2-ff7ac300-240.dhcp.inet.fi [88.195.122.240]) by mx.google.com with ESMTPS id h55sm5013364eeb.9.2011.05.11.04.53.42 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 11 May 2011 04:53:43 -0700 (PDT) Message-ID: <4DCA78C5.4040803@enterprisedb.com> Date: Wed, 11 May 2011 14:53:41 +0300 From: Heikki Linnakangas User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; fi-FI; rv:1.9.1.16) Gecko/20110505 Icedove/3.0.11 MIME-Version: 1.0 To: Fujii Masao CC: Robert Haas , Jaime Casanova , pgsql-hackers@postgresql.org Subject: Re: time-delayed standbys References: <4DCA5BEC.2020805@enterprisedb.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: 201105/635 X-Sequence-Number: 187669 On 11.05.2011 14:16, Fujii Masao wrote: > On Wed, May 11, 2011 at 6:50 PM, Heikki Linnakangas > wrote: >> I think we can just always call ShutdownWalRcv(). It should be gone if the >> server was promoted while streaming, but that's just an implementation >> detail of what the promotion code does. There's no hard reason why it >> shouldn't be running at that point anymore, as long as we kill it before >> going any further. > > Okay. But I'd like to add the following assertion check just before > ShutdownWalRcv() which you added, in order to detect such a bug > that we found this time, i.e., the bug which causes unexpected end > of recovery. Thought? > > Assert(reachedStopPoint || !WalRcvInProgress()) There's no unexpected end of recovery here. The recovery ends when we reach the target, as it should. It was the assumption that WAL receiver can't be running at that point anymore that was wrong. That assertion would work, AFAICS, but I don't think it's something we need to assert. There isn't any harm done if WAL receiver is still running, as long as we shut it down at that point. >> Committed a patch to do that. > > Thanks. Should we backport it to 9.0? 9.0 has the same problem. Ah, thanks, missed that, Cherry-picked to 9.0 now as well. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com