Feedback-ID: i0fe9450f:Fastmail
Date: Fri, 11 Aug 2023 15:08:26 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Noah Misch <noah@leadboat.com>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>, thomas.munro@gmail.com,
	exclusion@gmail.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17928: Standby fails to decode WAL on termination of primary
Message-ID: <ZNXQWvnmt1Fpt6vu@paquier.xyz>
References: <72bd036d-4f2a-8d50-b56e-6b1e3b9ba0a9@gmail.com>
 <CA+hUKG+t8gfYBS2TRMW6rHaWUBEC1Cy+p-0pgPBx8ag8TBeoKw@mail.gmail.com>
 <20230710200012.GB3476234@rfd.leadboat.com>
 <20230711.155414.939136339819647605.horikyota.ntt@gmail.com>
 <20230717004905.GE3826297@rfd.leadboat.com>
 <ZNSVlR/v8gTDIMsU@paquier.xyz>
 <20230811025808.GA2261232@rfd.leadboat.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="xWtGtYDtySwsU8q6"
Content-Disposition: inline
In-Reply-To: <20230811025808.GA2261232@rfd.leadboat.com>
Archived-At: 
 <https://www.postgresql.org/message-id/ZNXQWvnmt1Fpt6vu%40paquier.xyz>
Precedence: bulk


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

On Thu, Aug 10, 2023 at 07:58:08PM -0700, Noah Misch wrote:
> On Thu, Aug 10, 2023 at 04:45:25PM +0900, Michael Paquier wrote:
>> Good idea to pollute the data with recycled segments.  Using a minimal
>> WAL segment size whould help here as well in keeping a test cheap, and
>> two segments should be enough.  The alignment calculations and the
>> header size can be known, but the standby records are an issue for the
>> predictability of the test when it comes to adjust the length of the
>> logical message depending on the 8k WAL page, no?
>=20
> Could be.  I expect there would be challenges translating that outline in=
to a
> real test, but I don't know if that will be a major one.  The test doesn't
> need to be 100% deterministic.  If it fails 25% of the time and is not the
> slowest test in the recovery suite, I'd find that good enough.

FWIW, I'm having a pretty hard time to get something close enough to a
page border in a reliable way.  Perhaps using a larger series of
records and select only one would be more reliable..  Need to test
that a bit more.

>> FWIW, I came back to this thread while tweaking the error reporting of
>> xlogreader.c for the sake of this thread and this proposal is an
>> improvement to be able to make a distinction between an OOM and an
>> incorrect record:
>> https://www.postgresql.org/message-id/ZMh/WV+CuknqePQQ@paquier.xyz
>>=20
>> Anyway, agreed that it's an improvement to remove this check out of
>> allocate_recordbuf().  Noah, are you planning to work more on that?
>=20
> I can push xl_tot_len-validate-v1.patch, particularly given the testing r=
esult
> you reported today.  I'm content for my part to stop there.

Okay, fine by me.  That's going to help with what I am doing in the
other thread as I'd need to make a better difference between the OOM
and the invalid cases for the allocation path.

You are planning for a backpatch to take care of the inconsistency,
right?  The report has been on 15~ where the prefetching was
introduced.  I'd be OK to just do that and not mess up with the stable
branches more than necessary (aka ~14) if nobody complains, especially
REL_11_STABLE planned to be EOL'd in the next minor cycle.
--
Michael

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

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

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmTV0FoACgkQnvQgOdby
QH22Rw//TSzymVxYhLeREKwbF+32regdKV4i82KCHkzJIScA8rxrHpHkKsb1scYX
Dak466gpeFn5ivp08fsp7WYhT1nIuCUBZ7cGBz1rzbw1eCGxDeKQAlwy4IBLhzQ2
nsAeWlsxFMvkT6SZAHNDqBvuOP796bvgpg9T3PQarV/dqXAcC8NzmGV3MCMq1fsR
Qo24mi4SwtcW1kMuS4S5VzTPV91RQbEVw64tX2YygKEMuv4+qLmeKyOnGaGffGjx
KXWhZkTgsn2THT2lw1h4bbpEwpcnruo9e4DUzCOvK9Fl9/+TBqypARU6fiKwA0zv
yHf20pKhjoxdvXiJdXUhl1fU4HhFVWBqp4A5WRc0zworvBT5TU+kKpWsvW16Bivk
zPxJp9yMBA20VWkTdJmd7wEKrI058LkI2jdh5vsu90iz9HcyRwEWXfhqHniFVSYz
kCo8u2XC/6akK3cRbUJaCUActewmxHy1K4lZEgoufU3VcJEejuOhhzO7b71qJK7w
jAddkzYsAuouc0JTneLw7IR/6uH6uLL3bgCi23fd5bRR9tNmUNS0GEuBwkR2+X+S
5J06Pk4Ml1Qqah2yYlow4xprXBk2d4kreIRibdElT1RR3lbwqAf2z92tD7IUNSx1
tAXtg6Yxx5nH39fP0u4YOtD6PoeKvybaKN+0s1AUUiqEyVXU+cI=
=s5g2
-----END PGP SIGNATURE-----

--xWtGtYDtySwsU8q6--