From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <vdavydov.dev@gmail.com>
Date: Fri, 8 Jun 2018 09:43:02 +0300
From: Vladimir Davydov <vdavydov.dev@gmail.com>
Subject: Re: [RFC PATCH 06/12] box: refactor hot standby recovery
Message-ID: <20180608064302.2xmkbnwwaovy5kg6@esperanza>
References: <cover.1528305232.git.vdavydov.dev@gmail.com>
 <27aabda1063798f83ca4415c01001838bded35c4.1528305232.git.vdavydov.dev@gmail.com>
 <20180608044045.GO6866@chai>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20180608044045.GO6866@chai>
To: Konstantin Osipov <kostja@tarantool.org>
Cc: tarantool-patches@freelists.org
List-ID: <tarantool-patches.dev.tarantool.org>

On Fri, Jun 08, 2018 at 07:40:45AM +0300, Konstantin Osipov wrote:
> * Vladimir Davydov <vdavydov.dev@gmail.com> [18/06/06 20:45]:
> > Currently, we start a hot standby fiber even if not in hot standby mode
> > (see recovery_follow_local). And we scan the wal directory twice - first
> > time in recovery_follow_local(), second time in recovery_finalize().
> > Let's factor out recover_remaining_wals() from those functions and call
> > it explicitly. And let's start call follow_local() and stop_local() only
> > if in hot standby mode.
> 
> In hot standby mode, we need to make sure we scan all the WALs at
> least once after we acquired a path lock. 
> 
> As far as I understand this patch, it removes this property.

No, it doesn't. See, even though it removes recover_remaining_wals()
from recovery_finalize(), it makes hot_standby_f() call it before
returning, so that we will rescan the xlog dir just before leaving
hot standby mode:

> @@ -490,6 +486,7 @@ hot_standby_f(va_list ap)
>  
>  		subscription.events = 0;
>  	}
> +	recover_remaining_wals(r, stream, NULL, true);
>  	return 0;
>  }