Feedback-ID: i0fe9450f:Fastmail
Date: Sun, 7 Jan 2024 16:10:50 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Alexander Lakhin <exclusion@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Euler Taveira <euler@eulerto.com>,
	Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>,
	Kyotaro Horiguchi <horikyota.ntt@gmail.com>,
	Alvaro Herrera <alvherre@alvh.no-ip.org>,
	Andrew Dunstan <andrew@dunslane.net>,
	pgsql-hackers@lists.postgresql.org,
	Andres Freund <andres@anarazel.de>,
	Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Subject: Re: Add a perl function in Cluster.pm to generate WAL
Message-ID: <ZZpOenv6gv8TdZLE@paquier.xyz>
References: <3a6978d6-e4fc-4014-b5f7-45db53d8fa53@app.fastmail.com>
 <ZYEaLlhZ5lgTqsaQ@paquier.xyz>
 <CALj2ACXppTLS1pKa=M-h-VxWHSTo4iJvHYik_J+pLQxdeLMAzQ@mail.gmail.com>
 <ZYIgg55UyDS56Y9l@paquier.xyz>
 <5d160064-8cbe-4b32-9c55-c983b1f63b12@app.fastmail.com>
 <ZYOTKV1MV7gDYpCV@paquier.xyz>
 <370894.1704325169@sss.pgh.pa.us>
 <2e203472-72b5-1b55-377a-824c3f28b190@gmail.com>
 <ZZdD0U0_cSZT4ZhA@paquier.xyz>
 <2d39b5fa-ba90-48c8-4cde-ecba4a62fa3b@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="g7zDvfquhOLSxU4O"
Content-Disposition: inline
In-Reply-To: <2d39b5fa-ba90-48c8-4cde-ecba4a62fa3b@gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/ZZpOenv6gv8TdZLE%40paquier.xyz>
Precedence: bulk


--g7zDvfquhOLSxU4O
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Jan 05, 2024 at 11:00:00PM +0300, Alexander Lakhin wrote:
> Your suspicion was proved right. After
> git show c161ab74f src/test/recovery/t/035_standby_logical_decoding.pl=A0=
 | git apply -R
> 20 iterations with 20 tests in parallel performed successfully for me
> (twice).
>=20
> So it looks like c161ab74f really made the things worse.

We have two different failures here, one when VACUUM fails for a
shared relation:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=3Dskink&dt=3D2024-0=
1-03%2017%3A09%3A27
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=3Dskink&dt=3D2024-0=
1-01%2020%3A10%3A18

And the second failure happens for VACUUM FULL with a shared relation:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=3Dskink&dt=3D2024-0=
1-03%2020%3A07%3A15

In the second case, the VACUUM FULL happens *BEFORE* the new
advance_wal(), making c161ab74f unrelated, no?

Anyway, if one looks at the buildfarm logs, this failure is more
ancient than c161ab74f.  We have many of them before that, some
reported back in October:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=3Dskink&dt=3D2023-1=
0-19%2000%3A44%3A58
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=3Dskink&dt=3D2023-1=
0-30%2013%3A39%3A20

I suspect on the contrary that c161ab74f may be actually helping here,
because we've switched the CREATE TABLE/INSERT queries to not use a
snapshot anymore, reducing the reasons why a slot conflict would
happen?  Or maybe that's just a matter of luck because the test is
racy anyway.

Anyway, this has the smell of a legit bug to me.  I am also a bit
dubious about the choice of pg_authid as shared catalog to choose for
the slot invalidation check.  Isn't that potentially racy with the
scans we may do on it at connection startup?  Something else should be
chosen, like pg_shdescription as it is non-critical?  I am adding in
CC Bertrand and Andres, as author and committer behind befcd77d53217b.
--
Michael

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

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

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmWaTnoACgkQnvQgOdby
QH2c5A/8DO+2TbwjgJ0BrLGDNSe1NJ2CQS5cemh5jPWEV4Jz2OoZCx9UBjJiN3N/
6mI72BoROa/Qnv3q0JsVzFKATW2uxR6xtMTaq29o3/gzAvCb4PthlhV5qocWqP6L
F42lgHhRbsRPbEz/xcu4FBDM/AHtwGJfYIDsGPyDQGCxp52VL8eB2KGKbPX2kLUG
q2zkZRK71EAsXZba9EtIBp+P43jk7dNJ4PfwHC9GJtB+fKOgDkd7czL4SCSx7UcA
6vR3/7gzEI4x9xmXoeUE7JRZxftM9F5P254sxS6DHu2FLq/TMLL4/xxrn5vB68QN
w6jOISFT7zBQG+s24oFqn9qx+ge85EbqG4xIJM6QS/m2abU6Bq/vUPbnV6M4WFuK
5/sVkSPM5CCjzizOkQne2v56YmEWmwDRWFdr3Cr1ds118pdU9iuTlU5sI9/ApdIl
IBQI+hfrdLohM4suem/Z5D/azNZDoW5ful919mE/ppwQlS48tkmHbFJvHniL+sAI
BK9OaSkDua+PozW6oZXy12jfPArjLhanPbeOxgpoi2q1oRDiu7FvhjZcIduzLR2b
cniDzXqJ1OW5IMnHEqfQGUD+6qd3DoAdxTc+6cYWWkryj8PBYV8MzALAA8IU5+GD
YTrho5cnKz+K9FEDLY6uZNxR/rCc01jSsDa2tAt7uq/oWqzZFF0=
=i0OL
-----END PGP SIGNATURE-----

--g7zDvfquhOLSxU4O--