Date: Fri, 8 Nov 2019 09:01:33 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andres Freund <andres@anarazel.de>, pgsql-hackers@lists.postgresql.org
Subject: Re: SKIP_LOCKED test causes random buildfarm failures
Message-ID: <20191108000133.GS1768@paquier.xyz>
References: <25294.1573077278@sss.pgh.pa.us>
 <20191106230111.2kmd6hnriqttw6ys@alap3.anarazel.de>
 <20191107013942.GA1768@paquier.xyz>
 <12732.1573145425@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="xPLL5cPndR2UZ7Mw"
Content-Disposition: inline
In-Reply-To: <12732.1573145425@sss.pgh.pa.us>
Precedence: bulk


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

On Thu, Nov 07, 2019 at 11:50:25AM -0500, Tom Lane wrote:
> Michael Paquier <michael@paquier.xyz> writes:
>> Good question.  That's a historical choice, still I have seen cases
>> where those warnings are helpful while not making the logs too
>> verbose to see some congestion in the jobs.
>=20
> I kind of feel that NOTICE is more semantically appropriate, but
> perhaps there's an argument for keeping it at WARNING.

Perhaps.  Well, that's the same level as the one used after the
permission checks on the relation vacuumed.

> I do not want to fix this in the main tests by disabling autovacuum,
> because that'd actually reduce the tests' cross-section.  The fact
> that this happens occasionally is a Good Thing for verifying that the
> code paths actually work.  So it seems that there's a consensus on
> adjusting client_min_messages to fix the test output instability ---
> but we need to agree on whether to do s/WARNING/NOTICE/ first, so we
> can know what to set client_min_messages to.

Makes sense.=20

> As for the case in the isolation test, shouldn't we also use
> client_min_messages there, rather than prevent the conflict
> from arising?  Or would that test fail in some larger way if
> autovacuum gets in the way?

I think that there is no risk regarding the stability of the output
because we use LOCK before from a first session on the relation to
vacuum in a second session.  So if autovacuum runs in parallel, the
consequence would be a small slow down while waiting on the lock to be
taken.  And per the way the test is ordered, it seems to me that it
makes the most sense to disable autovacuum as it would just get in the
way.  In this case I think that it is actually better to show the
messages as that makes the tests more verbose and we make sure to test
their format, even if we could just rely on the fact that VACUUM
should just be blocking or non-blocking.
--
Michael

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

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

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAl3EsF0ACgkQnvQgOdby
QH32qA//ZJYnz7ztXlm6T6RK8cCoDl+G8VM+E526eUxrKgPcpM68NT7/qwCvSrP5
fb8RrLQOuD4vjUQLuT9Qs1MNzs6E6H1SCtSqaXAeqrzRSldMnzpiAK64UTLFq0zc
F0nhHcYXiknQ3n1jDkAE2udumaEXpfucDkGA8ow5JhgXatWsTaEMWmOn5aTEuM2S
XcOERKIo/hWH6ugHR3rUZyhQkEwz+7fRnpdaXPeU8/Rsr53/QICjqMGOH9VeJPCl
ZiFrpL6GeWU//QkY/yINrlO9A7ctUnuNEvNtRW68zdNLSjR52GI4DgWCO5Th5KFF
9/zeL20B3PadHoDBAprC+0CbxQ2APIe7M2X8sZ3hIaSgDptT63g9sKfxYGB/X+7k
t9Nect0/Iw03v1J2bvhFlpFppNR3i4i8CGiR7GVxHEcgzTLxWaWM2NqJYjSYGffA
lwmV1+i4iMevyojBGNGNa+EQqYvB3yB3GKMmdHElMbLU5kKHZF4m8mcDO/J7s9RW
VvL37imsU5zR2VgUeK46sDB0JoGJBak32GH0EmhOUbD+0XXgkcWb+rW6Y8uWLMOH
NjsRUyZFsX1HtaWu+lIDaX4YBngqUB4dbv43UGii1sXZXiUx+CO0uOhVWWcoA3dL
GgpXGpV1ko45cWR03j1BTT2X6ybhvw4LsKAEG4nAyquNi8k4C2E=
=vLo5
-----END PGP SIGNATURE-----

--xPLL5cPndR2UZ7Mw--