Date: Fri, 29 Mar 2019 20:51:38 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>
Cc: Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>,
	sawada.mshk@gmail.com, tgl@sss.pgh.pa.us, alvherre@2ndquadrant.com,
	sk@zsrv.org, nasbyj@amazon.com, andres@anarazel.de,
	robertmhaas@gmail.com, pgsql-hackers@lists.postgresql.org
Subject: Re: pgsql: Improve autovacuum logging for aggressive and
 anti-wraparound ru
Message-ID: <20190329115138.GD1954@paquier.xyz>
References: 
 <CAD21AoBR+y31ps+=G6_fxxVd_o1itTnaK19sDAEhAP_RyVT2AA@mail.gmail.com>
 <20181005031603.GF1629@paquier.xyz>
 <20181005063504.GB14664@paquier.xyz>
 <20181009.181536.142257785.horiguchi.kyotaro@lab.ntt.co.jp>
 <920b7f84-407c-005c-4b7d-e8266a17d22b@2ndQuadrant.com>
 <20190309011537.GD9266@paquier.xyz>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="d8Lz2Tf5e5STOWUP"
Content-Disposition: inline
In-Reply-To: <20190309011537.GD9266@paquier.xyz>
Precedence: bulk


--d8Lz2Tf5e5STOWUP
Content-Type: multipart/mixed; boundary="OROCMA9jn6tkzFBc"
Content-Disposition: inline


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

On Sat, Mar 09, 2019 at 10:15:37AM +0900, Michael Paquier wrote:
> I am adding an open item about that.  I think I could commit the
> patch, but I need to study it a bit more first.

So, coming back to this thread, and studying the problem again, it
looks that the diagnostic that a non-aggressive, anti-wraparound
vacuum could be triggered because the worker sees trouble in the
force because of some activity happening in parallel.  Hence, if we
face this case, it looks right to skip the vacuum for this relation.

Attached is an updated patch with a better error message, more
comments, and the removal of the anti-wraparound non-aggressive log
which was added in 28a8fa9.  The error message could be better I
guess.  Suggestions are welcome.

Thoughts?
--
Michael

--OROCMA9jn6tkzFBc
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment; filename="autovac-antiwrap-skip.patch"
Content-Transfer-Encoding: quoted-printable

diff --git a/src/backend/access/heap/vacuumlazy.c b/src/backend/access/heap=
/vacuumlazy.c
index 5c554f9465..82be8c81f3 100644
--- a/src/backend/access/heap/vacuumlazy.c
+++ b/src/backend/access/heap/vacuumlazy.c
@@ -248,6 +248,25 @@ heap_vacuum_rel(Relation onerel, VacuumParams *params,
 	if (params->options & VACOPT_DISABLE_PAGE_SKIPPING)
 		aggressive =3D true;
=20
+	/*
+	 * When running an anti-wraparound vacuum, we expect relfrozenxid to be
+	 * old enough so as aggressive is always set.  If this is not the case,
+	 * it could be possible that another concurrent vacuum process has done
+	 * the work for this relation so that relfrozenxid in relcache has
+	 * already been moved forward enough, causing this vacuum run to be
+	 * non-aggressive.  If that happens, note that this relation no longer
+	 * needs to be vacuumed, so just skip it.
+	 */
+	if (params->is_wraparound && !aggressive)
+	{
+		ereport(LOG,
+				(errmsg_internal("found vacuum to prevent wraparound of table \"%s.%s.=
%s\" to be not aggressive, so skipping",
+								 get_database_name(MyDatabaseId),
+								 get_namespace_name(RelationGetNamespace(onerel)),
+								 RelationGetRelationName(onerel))));
+		return;
+	}
+
 	vacrelstats =3D (LVRelStats *) palloc0(sizeof(LVRelStats));
=20
 	vacrelstats->old_rel_pages =3D onerel->rd_rel->relpages;
@@ -375,10 +394,9 @@ heap_vacuum_rel(Relation onerel, VacuumParams *params,
 			initStringInfo(&buf);
 			if (params->is_wraparound)
 			{
-				if (aggressive)
-					msgfmt =3D _("automatic aggressive vacuum to prevent wraparound of ta=
ble \"%s.%s.%s\": index scans: %d\n");
-				else
-					msgfmt =3D _("automatic vacuum to prevent wraparound of table \"%s.%s=
=2E%s\": index scans: %d\n");
+				/* an anti-wraparound vacuum has to be aggressive */
+				Assert(aggressive);
+				msgfmt =3D _("automatic aggressive vacuum to prevent wraparound of tab=
le \"%s.%s.%s\": index scans: %d\n");
 			}
 			else
 			{

--OROCMA9jn6tkzFBc--

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

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

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAlyeBsoACgkQnvQgOdby
QH0a1A//cmganeiY/BHrUI24k1VkK0OBjWypK1thwQ2rGGzZYEc+MiazNLFxyEJs
S+Wa1DQ1YKQ8O/D9GiTIQsmmZM60WF2TlXOMfvlqaZzdj/zSsUoZv23UsbeqM8I/
CdNlgxesWeqRz87GkA0dJ+pCTdb8sBQSctEzCLCS3gxlhtxf+nhd38nobNc3y92C
/3z246G9QL8Mj994VIz5L5Sd3fDKHiUNr0k5wMO3lGf/QbH4vVF/C5t24TxybEEg
MXgB+qLMnn83At5zK0pW5pOnoIkD7t2zALbKNMGj07p5qmffnOphDeWWXH38gSyL
YClzQrDviP0Mq5vjqME82XnAjlMetPCleEK4cxlwEWJf21woRGnEse4bBDCNzJx1
KLxcPhIvP5iCdQorQcOBdEYx21tuRWsTjWRR3t5e8x3//y8lDlmFntY+LLd3R52M
cia43FsHPaxu+A5dQ+SAn9WXwKqK6/cDHhAMC3TwmcTYvXI5dtb027OC4ZmgU92d
WHgC3hcQRme21rVrPq2jfbWViyODbvSFFCm4gBwEmufqrozfpxXLiN/CfJ+ALOEg
n7ZTEyWHvwb/FtCa1KWRTuqrVWEfgKzYG3DqVkdUAXuDYHSKBIjEAZKb7B+ThnIH
e0yRGTqdKUJjbA9mpxXRRkLYzcrqSjIlKB5Du77MhlJHL2yvcE0=
=11jD
-----END PGP SIGNATURE-----

--d8Lz2Tf5e5STOWUP--