Date: Mon, 23 Mar 2020 18:41:50 -0700
From: Andres Freund <andres@anarazel.de>
To: Michael Paquier <michael@paquier.xyz>
Cc: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>,
	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, robertmhaas@gmail.com,
	pgsql-hackers@lists.postgresql.org
Subject: Re: pgsql: Improve autovacuum logging for aggressive and
 anti-wraparound ru
Message-ID: <20200324014150.2nyuygbbejzaybip@alap3.anarazel.de>
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>
 <20190329115138.GD1954@paquier.xyz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20190329115138.GD1954@paquier.xyz>
Precedence: bulk

Hi,

On 2019-03-29 20:51:38 +0900, Michael Paquier wrote:
> 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.

> 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 = true;
>  
> +	/*
> +	 * 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;
> +	}
> +

Which valid scenario can lead to this? Neither the comment, nor commit
message explain it. Unless you're thinking of scenarios where autovacuum
and manual vacuum are mixed, I don't really see valid reasons? Normally
autovacuum's locking + the table_recheck_autovac() check should prevent
problematic scenarios.

I do see a few scenarios that can trigger this - but they all more or
less are bugs.

It doesn't strike me as a good idea to work around such bugs by silently
neutering heap_vacuum_rel(). The likelihood of that temporarily covering
up more severe problems seems significant - they're likely to then later
bite you with a cluster shutdown.

Greetings,

Andres Freund