Date: Wed, 22 Apr 2020 16:14:20 +0200
From: Jehan-Guillaume de Rorthais <jgdr@dalibo.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>,
 masao.fujii@oss.nttdata.com, pgsql-bugs@lists.postgresql.org
Subject: Re: [BUG] non archived WAL removed during production crash recovery
Message-ID: <20200422161420.1e82be3d@firost>
In-Reply-To: <20200422011935.GF33034@paquier.xyz>
References: <20200417065043.GC350229@paquier.xyz>
	<20200417153304.01a226cc@firost>
	<20200418092611.GD350229@paquier.xyz>
	<20200420.160231.719176619682386260.horikyota.ntt@gmail.com>
	<20200420073444.GA77439@paquier.xyz>
	<20200420142235.1536a73b@firost>
	<20200421021501.GE77439@paquier.xyz>
	<20200422004121.516a5a32@firost>
	<20200422011935.GF33034@paquier.xyz>
Organization: Dalibo
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Precedence: bulk

On Wed, 22 Apr 2020 10:19:35 +0900
Michael Paquier <michael@paquier.xyz> wrote:

> On Wed, Apr 22, 2020 at 12:41:21AM +0200, Jehan-Guillaume de Rorthais wrote:
> > Do we need to acquire info_lck to look at the state here, as we do in
> > GetRecoveryState()? Why is it missing from previous code where
> > SharedRecoveryInProgress was protected by info_lck as well?  
> 
> Please see 1a3d104.

Understood. Interesting. Thank you.

> > Plus, the new line length overflow the 80-column, but I'm not sure where to
> > break this line.  
> 
> pgindent has been run on v8, and it did not complain.

OK.

> > In fact, this was inherited from 011_crash_recovery.pl where I originally
> > added some tests. As 020_archive_status.pl doesn't use IPC::Run, the
> > comment is wrong. But I wonder if this whole block is really needed.
> > Unfortunately I can't test on MSWin32 :/  
> 
> You are right here.  The restriction can be removed, and I have
> checked that the test from v8 is able to pass on my Windows dev VM.

Thanks!