Date: Mon, 16 May 2022 12:47:29 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: nathandbossart@gmail.com, pgsql-hackers@lists.postgresql.org,
	masao.fujii@oss.nttdata.com
Subject: Re: Possible corruption by CreateRestartPoint at promotion
Message-ID: <YoHJUSht3ulTO/z1@paquier.xyz>
References: <YmjRkYo2Ce+mO5WO@paquier.xyz>
 <20220427180945.GA3222843@nathanxps13>
 <Ymnb3XlT4YwJ5yOH@paquier.xyz>
 <20220428.114357.476887320744154615.horikyota.ntt@gmail.com>
 <Ymo5BlhEzvXhHObF@paquier.xyz>
 <YnT/Y2sEYj7pyOdc@paquier.xyz>
 <YnhfJir8WYRIWgAs@paquier.xyz>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="LmgdLG2nXDvdEJN9"
Content-Disposition: inline
In-Reply-To: <YnhfJir8WYRIWgAs@paquier.xyz>
Archived-At: 
 <https://www.postgresql.org/message-id/YoHJUSht3ulTO/z1%40paquier.xyz>
Precedence: bulk


--LmgdLG2nXDvdEJN9
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, May 09, 2022 at 09:24:06AM +0900, Michael Paquier wrote:
> Okay, applied this one on HEAD after going back-and-forth on it for
> the last couple of days.  I have found myself shaping the patch in
> what looks like its simplest form, by applying the check based on an
> older checkpoint to all the fields updated in the control file, with
> the check on DB_IN_ARCHIVE_RECOVERY applying to the addition of
> DB_SHUTDOWNED_IN_RECOVERY (got initialially surprised that this was
> having side effects on pg_rewind) and the minRecoveryPoint
> calculations.

It took me some time to make sure that this would be safe, but done
now for all the stable branches.

> Now, it would be nice to get a test for this stuff, and we are going
> to need something cheaper than what's been proposed upthread.  This
> comes down to the point of being able to put a deterministic stop
> in a restart point while it is processing, meaning that we need to
> interact with one of the internal routines of CheckPointGuts().  One
> fancy way to do so would be to forcibly take a LWLock to stuck the
> restart point until it is released.  Using a SQL function for that
> would be possible, if not artistic.  Perhaps we don't need such a
> function though, if we could stuck arbitrarily the internals of a=20
> checkpoint?  Any ideas?

One thing that we could do here is to resurrect the patch that adds
support for stop points in the code..
--
Michael

--LmgdLG2nXDvdEJN9
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmKByVEACgkQnvQgOdby
QH32Sg/+ImDU6ZPCNx0CrJsrgLt2mEexPIMAcnTm8/4jeRz5ezXa9EZQ/M0T3PUV
Q+g2x5BBPf4wChtoZFzmyYBcB36LzfVKQW4YSJIYd6SZSsK8ddP6cosnnRB9ZC9v
L1ou81CLekvhWShDBnzitmAUCK2ka+I3xYra1ifoM5x7HfTf2xphh2nOxZIlD4T+
2fotv41tv9FSKvJ+5nF88unfow2j2BRwwHkJKYQKKzy0n4HkxfcYAXjosyExv+9p
0821Ji3LNFG+BqTgFSwgaXKJ3JyPrrilb1V3O2lt40uYTB7SEEXro0FL6HsobDGj
OLoWPLFipoAkG+gKripzVsFXdbGoX2abxZfHcgbw+j9voSiSy/A2o9NyRUPMKPCj
BFiMJkKM+HLVcmWw0AH8A6LDLqSN3QhTbeK0N1SaDzje75O7KkqEuW9KPxtKV7qF
V1sNwnwNjHVbVru2L3Gr8FZAW3RPgixyN51z90tMB260Sgz+dHIYFShBjCVlo4Bn
7dGkLdZ8VCxqCelwcFvo2d0W29zoBG5NBSjNkNsz2JcRwLloMK8rlFXqjLNvcMoK
bJtX20yQwMOAF+PxaiCD/B+no/uo812SViEDVBJssfsp0dpljtsOI33zJHHxjSYa
7hypiHLGxI9wM4ZGt0b0P0EB+SiWRS/HWCHy3Sm2gqJmm4I6SfY=
=6dRf
-----END PGP SIGNATURE-----

--LmgdLG2nXDvdEJN9--