Feedback-ID: i0fe9450f:Fastmail
Date: Mon, 25 Sep 2023 08:58:45 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Alexander Lakhin <exclusion@gmail.com>, Sergei Kornilov <sk@zsrv.org>,
	Noah Misch <noah@leadboat.com>, Tom Lane <tgl@sss.pgh.pa.us>,
	Kyotaro Horiguchi <horikyota.ntt@gmail.com>,
	pgsql-bugs@lists.postgresql.org,
	Fujii Masao <masao.fujii@oss.nttdata.com>, pgbf@twiska.com
Subject: Re: BUG #17928: Standby fails to decode WAL on termination of primary
Message-ID: <ZRDNNf8Etlvuo48a@paquier.xyz>
References: <ZQpCG5QanJQXNVH-@paquier.xyz>
 <CA+hUKGKJx=S77ttAtJ_iA=oBGUf2VTnfUp-gtJEhdXCbmdkoAA@mail.gmail.com>
 <ZQ0R4kz3gN6bqS1N@paquier.xyz>
 <CA+hUKGK1+3rj3c7L9HPCc8HajTVmkTx1CEkU5=rqgV3b4OvWeQ@mail.gmail.com>
 <ZQ4r1vHcryBsSi_V@paquier.xyz>
 <CA+hUKGKs=yj55ejAwuUJQuURU=uKjYgRqEQcCi1GrP2+=jUgNQ@mail.gmail.com>
 <ZQ5tIoarrcwAlbVZ@paquier.xyz>
 <CA+hUKGJf3Hhb2MB88-rW2di2H9XT0xr6-hd6ZjGEwdJs3A=b+Q@mail.gmail.com>
 <ZQ9zf1QO8CP4TZRO@paquier.xyz>
 <CA+hUKGKo5O_f8aBDoEMkxHmuWdFfmPPo6wL4q85b_0PDuHwZEA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="mzNPzprC6dJsQxHI"
Content-Disposition: inline
In-Reply-To: 
 <CA+hUKGKo5O_f8aBDoEMkxHmuWdFfmPPo6wL4q85b_0PDuHwZEA@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/ZRDNNf8Etlvuo48a%40paquier.xyz>
Precedence: bulk


--mzNPzprC6dJsQxHI
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Mon, Sep 25, 2023 at 09:02:35AM +1300, Thomas Munro wrote:
> I see there was a failure on 16 on the very slow AIX box, and I have
> access so looking into that...

Lucky you, if I may say ;)

A bunch of architectures that are not Intel are failing.  Here is a
summary based on the buildfarm reports:
topminnow, mips64el with gcc 4.9.2
mereswine, ARMv7 with gcc 10.2.1
sungazer, ppc64 with gcc 8.3.0
frogfish, mips64el with gcc 4.6.3
mamba, macppc with gcc 10.4.0
gull, ARMv7 with clang 13.0.0
grison, ARMv7 with gcc 4.6.3
copperhead, riscv64 with gcc 10.X

The only thing close to that I have close by is tanager on Armv7 (it
has not reported to the buildfarm for a few weeks as it has
overheated because of the summer here, but I've put it back online
now).  However, it has passed a few hundred cycles with both gcc and
clang yesterday, on top of having a clean buildfarm run.

With sungazer now failing on REL_16_STABLE, it feels to me that we are
actually looking at two bugs?  One on HEAD, and one in stable
branches?  For HEAD and the 2PC failure, the records up to PREPARE
TRANSACTION should be replayed by the standby getting promoted, but
I'd rather dig into that with a host that's able to report the
failure.

copperhead seems to be one of the failing hosts that's able to compile
things quickly.  Tom, Noah, or copperhead's owner, could it be
possible to get access to one of the hosts that are failing for more
investigation?  I would not do more than compiling the code and check
after the state of the 2PC test for this promotion failure.
--
Michael

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

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

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmUQzTUACgkQnvQgOdby
QH3V6Q/+MxxWjuZuzCoL8db6VU0Ddt9ZUavKTBu3qYOSbiDB8Vb1EgCLWCYBYCFd
c7CjiDipsqUIzAmloaMqf2Mi2O43FjZh81zukwU3D0TZfFKnYU0SY7TAEZKpVB5a
JsxjpLcaXIyDwihBCpKMPwf6s2e4rz+5J8zBaujD8RAUg6LCeWoQ8DoLtFz/Qvoa
j/F7v1Rw2w5wARkt+brajByS8Sjmo3VjnRJxHgq81EKUZ96wP/tC20M/EwpXfN7D
vBDGjoq+z8Ib6bdfWd7aEIjMx/cawt1X4mZTRNwc+9ScMWL2D4Blqnf+g5NHfby8
HwoDUfAG7NKyROM2W5gc1qBKq+HihLc6rH74Z7ll8rTbf/RZrRi04kGGmuCIhtgS
JhXqCLEwUkU3gYzLw5iRk2uPtHl+kLfOTwADkFlRk6Vcy4RCt1Zm64JXOer+EbAR
SBjgiwm4as5wnEwWMXuLHS/2ZtqxnOj+FVs4cBTqpQ5XXg0Bcn0hw0N1X3uf1m+W
5WPw9xBVn9S/uYTOyASvXniYYmB+s2Lk88bMQLWcH+nKFl59NOAREL5fOF0O/lky
A3+E82GjqRX3LWouQEySwi8D2dWmV6AuZbc9La2YcxnDs20cY1JLG8/9Y3wzQTpo
tNBrvYyqyX1K/v3RvGp6E1cUc1b64kNi0mFxsLYiCK18J5gjuTU=
=1/vt
-----END PGP SIGNATURE-----

--mzNPzprC6dJsQxHI--