Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id 98A021337B69 for ; Wed, 11 May 2011 06:27:18 -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 62338-06 for ; Wed, 11 May 2011 09:27:08 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by mail.postgresql.org (Postfix) with ESMTP id 182321337B8B for ; Wed, 11 May 2011 06:27:07 -0300 (ADT) Received: from mail-ey0-f179.google.com ([209.85.215.179]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKTcpWa51VxFy2sFGs5Lm6Hi862pZO9ygG@postini.com; Wed, 11 May 2011 02:27:08 PDT Received: by eyg5 with SMTP id 5so94831eyg.38 for ; Wed, 11 May 2011 02:27:06 -0700 (PDT) Received: by 10.213.21.141 with SMTP id j13mr3268243ebb.109.1305106026190; Wed, 11 May 2011 02:27:06 -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 z1sm1410192eeb.21.2011.05.11.02.27.04 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 11 May 2011 02:27:05 -0700 (PDT) Message-ID: <4DCA5666.50506@enterprisedb.com> Date: Wed, 11 May 2011 12:27:02 +0300 From: Heikki Linnakangas User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; fi-FI; rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11 MIME-Version: 1.0 To: Robert Haas CC: Jaime Casanova , pgsql-hackers@postgresql.org Subject: Re: time-delayed standbys References: 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/617 X-Sequence-Number: 187651 On 07.05.2011 16:48, Robert Haas wrote: > I was able to reproduce something very like this in unpatched master, > just by letting recovery pause at a named restore point, and then > resuming it. > > LOG: recovery stopping at restore point "stop", time 2011-05-07 > 09:28:01.652958-04 > LOG: recovery has paused > HINT: Execute pg_xlog_replay_resume() to continue. > (at this point I did pg_xlog_replay_resume()) > LOG: redo done at 0/5000020 > PANIC: wal receiver still active > LOG: startup process (PID 38762) was terminated by signal 6: Abort trap > LOG: terminating any other active server processes > > I'm thinking that this code is wrong: > > if (recoveryPauseAtTarget&& standbyState == > STANDBY_SNAPSHOT_READY) > { > SetRecoveryPause(true); > recoveryPausesHere(); > } > reachedStopPoint = true; /* see below */ > recoveryContinue = false; > > I think that recoveryContinue = false assignment should not happen if > we decide to pause. That is, we should say if (recoveryPauseAtTarget > && standbyState == STANDBY_SNAPSHOT_READY) { same as now } else > recoveryContinue = false. No, recovery stops at that point whether or not you pause. Resuming after stopping at the recovery target doesn't mean that you resume recovery, it means that you resume to end recovery and start up the server (see the 2nd to last paragraph at http://www.postgresql.org/docs/9.1/static/recovery-target-settings.html). It would probably be more useful to allow a new stopping target to be set and continue recovery, but the current pause/resume functions don't allow that. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com