Feedback-ID: i0fe9450f:Fastmail
Date: Wed, 16 Aug 2023 15:17:58 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Noah Misch <noah@leadboat.com>, Tom Lane <tgl@sss.pgh.pa.us>,
	Kyotaro Horiguchi <horikyota.ntt@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: <ZNxqFgo243DOar4L@paquier.xyz>
References: 
 <CA+hUKGKcSyHRppTyGZy7q29E1JVtQKdKCNzY0QARG3gfqpLaXg@mail.gmail.com>
 <20230813033034.GD2326466@rfd.leadboat.com>
 <ZNmMqEXJ6ECTQ0Ys@paquier.xyz>
 <CA+hUKGKWPvSJkQ1De6bjV311Xk+cXU8K7a=71-ypvxJGHom5aA@mail.gmail.com>
 <CA+hUKGLOgGh=9siEhACUsrZEAQPVEQWgn35cggeci0_cNbPSSw@mail.gmail.com>
 <ZNrdQSWe1flOfHN3@paquier.xyz>
 <CA+hUKGLzv=8g3MFwm+TGFu+7koypgmU7qKHni+nrEnuJ8P6eog@mail.gmail.com>
 <ZNrqTmKGnZwz9gPI@paquier.xyz>
 <ZNsXBFsFsKcCbP0q@paquier.xyz>
 <CA+hUKGLhFdd-G1DCk9Ze3KnQ_2jUkxyXvGwV_Ha=DWMrDnGHng@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="XyoPStSaLO2sygBR"
Content-Disposition: inline
In-Reply-To: 
 <CA+hUKGLhFdd-G1DCk9Ze3KnQ_2jUkxyXvGwV_Ha=DWMrDnGHng@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/ZNxqFgo243DOar4L%40paquier.xyz>
Precedence: bulk


--XyoPStSaLO2sygBR
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Aug 16, 2023 at 03:29:49PM +1200, Thomas Munro wrote:
> I hacked on this idea for quite a long time yesterday and today and
> came up with a set of tests for the main end-of-WAL conditions:
>=20
> =E2=96=B6 1/1 - xl_tot_len zero                                  OK
> =E2=96=B6 1/1 - xl_tot_len short                                 OK
> =E2=96=B6 1/1 - xl_prev bad                                      OK
> =E2=96=B6 1/1 - xl_crc bad                                       OK
> =E2=96=B6 1/1 - xlp_magic zero                                   OK
> =E2=96=B6 1/1 - xlp_magic bad                                    OK
> =E2=96=B6 1/1 - xlp_pageaddr bad                                 OK
> =E2=96=B6 1/1 - xlp_info bad                                     OK
> =E2=96=B6 1/1 - xlp_info lacks XLP_FIRST_IS_CONTRECORD           OK
> =E2=96=B6 1/1 - xlp_rem_len bad                                  OK
> =E2=96=B6 1/1 - xlp_magic zero (split record header)             OK
> =E2=96=B6 1/1 - xlp_pageaddr bad (split record header)           OK
> =E2=96=B6 1/1 - xlp_rem_len bad (split record header)            OK
> 1/1 postgresql:recovery / recovery/038_end_of_wal        OK
>     5.79s   13 subtests passed

Nice.

> It took me a while to come up with a workable way to get into the
> record-header-splitting zone.  Based on some of your clues about
> flushing, I eventually realised I needed transactional messages, and I
> built a kind of self-calibrating Rube Goldberg function around that.
> It's terrible, and I'm sure we can do better.

So that's advance_to_record_splitting_zone(), with the idea to loop
across multiple records.  The use of transactional messages ensures
the flush and the stability of the test when the server is stopped,
but it makes the records a bit longer than the non-transactional
messages.

> I wonder what people think about putting internal details of the WAL
> format into a Perl test like this.  Obviously it requires maintenance,
> since it knows the size and layout of a few things.  I guess it'd be
> allowed to fish a couple of those numbers out of the source.

The format of the WAL header does not change a lot across the years,
so I'd be OK with that.  If that's an issue, the scope of the test
could always be restricted a bit.

> Work in progress...  I'm sure more useful checks could be added.  One
> thing that occurred to me while thinking about all this it that the
> 'treat malloc failure as end of WAL' thing you highlighted in another
> thread is indeed completely bananas -- I didn't go digging, but
> perhaps it was an earlier solution to the very same garbage xl_tot_len
> problem, before 70b4f82a4b5 and now this xl_rem_len-based solution?

It is bananas.  Still, the problem of the other thread is similar to
what's here, and different at the same time because it can happen with
a valid record if the host is under memory pressure, and we should
still allow a standby to loop and continue in this case.  Perhaps also
a startup process doing only crash recovery.  This thread's problem is=20
dependent on this one, which is why this one needs to happen first: we
need to clarify the boundary between a real OOM and garbage indicating
the end of WAL.

+my $RECORD_HEADER_SIZE =3D 24;
+my $XLP_PAGE_MAGIC =3D 0xd113;
+my $XLP_FIRST_IS_CONTRECORD =3D 0x1;

This could use something like check_pg_config() to find the header
contents for the last two ones, but there's no easy way to extract the
size of the header struct, is there?  Or perhaps perl has a tool for
that..  Anything I can read on the matter tells to use pack() to make
the size estimations predictible.

+   my $page_offset =3D $end_lsn % $WAL_BLOCK_SIZE;
+   while ($page_offset >=3D $WAL_BLOCK_SIZE - 2000)
+   {
+       $end_lsn =3D emit_message($node, 2000)

The hardcoded 2000 feels magic here, but I get that you just want to
get away from the page border, as well.  I'd be OK with more comments.

+sub lsn_to_segment_and_offset
+{
+   my $lsn =3D shift;
+   return ($lsn / $WAL_SEGMENT_SIZE, $lsn % $WAL_SEGMENT_SIZE);
+}

Now the backend also has pg_walfile_name_offset().  I tend to rely on
the backend logic as much as I can for tests.

+sub start_of_page

Not sure this one is needed, only being called in
start_of_next_page().

+sub get_insert_lsn

Name is confusing with Cluster::lsn('insert') available, perhaps this
should be named get_insert_lsn_in_bytes.

As a whole, I find that pretty cool.  Not sure if I would backpatch
the test, so my opinion would be to use that on HEAD and let it
stabilize there.
--
Michael

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

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

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmTcahYACgkQnvQgOdby
QH1lyxAAipRM0l2u9HO+HCKPw1rtSf5ygHh668e9qqw6CGxw0TD+5c/oJcGG/ijy
0lplxst5AG3WJHpBB97Cet1Rw4fEfSCcbFKbHZSB30nzHlcl0b/wszzifjxyvflz
SK3tVVJdP+RookWIJCjuWhTxBkfLkNjxUNcIxxGjrmfFnY0N2vyxulzTwQILRhK5
NDMtTxrskYVHBWIkpj/v6Kc9n/3fjM6oGnP7CD0gijMnjIlKt5iGLRqYAUqBfRSF
Gul6DX/V1CBFeYYMLHVivoauK4l0DC8hA9jdQfBj5rXIm1DSxu5bQOuQQjAuFTMj
+ZUoRYnqUTmUYbf/8fMEquWE4wWk31A42mnK6G33PqadgTlDuABqs8OTjyuZ/rvJ
sNaJ8csfJzUvKNu33v8tu+8b0AldJRM4eBHE7+bz/y2Yq7a5HWXqrueTsg3m85uC
t0eB7hEZCyxb3RjEjWCOXTvDh4Sr1kAgWCfzZ9uNqlfo/HHZlLx+EhS/ZFrYu6WS
yPy570WNfcoOkPlCTb6SYiljSBTiyfcuMSFQJK/evNgOTE2lpozaREpqiHuc37Vr
noklV9zN+jV+ivRvIJFoFR7qfW2bXWkGEg+NB21EZU4BqsvnAoRBxHI8bqS8JDKm
senVB45iOs7Od0L1YzARP+BTcba3PHDUsWagvLcCrhyUPrEbsFA=
=wtxA
-----END PGP SIGNATURE-----

--XyoPStSaLO2sygBR--