Date: Mon, 20 Apr 2020 14:22:35 +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: <20200420142235.1536a73b@firost>
In-Reply-To: <20200420073444.GA77439@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>
Organization: Dalibo
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Mon, 20 Apr 2020 16:34:44 +0900
Michael Paquier <michael@paquier.xyz> wrote:
[...]
> > By the way I noticed that RecoveryState is exactly a subset of
> > DBState.  And changes of SharedRecoveryState happens side-by-side with
> > ControlFileData->state in most places.  Coundn't we just usee
> > ControlFile->state instead of SharedRecoveryState?
>=20
> I actually found confusing to use the same thing, because then the
> reader would thing that SharedRecoveryState could be set to more
> values but we don't want that.

I thought about this while studying various possible fix.=20

https://www.postgresql.org/message-id/flat/20200401181735.11100908%40firost=
#6192afba4e4549b8d9bac03168bad46b

The problem is that we would have to read the controldata file each time we
wonder if a segment should be archived/removed. Moreover, the controldata
file might not be in sync quickly enough with the real state for some other
code path or futur needs.

[...]
> Attached is an updated patch, where I tweaked more comments.
>=20
> Jehan-Guillaume, who is your colleague who found originally about this
> problem?  We should credit him in the commit message.

Indeed, Beno=C3=AEt Lobr=C3=A9au reported this behavior to me.

Regards,