From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Andrew Dunstan <andrew(dot)dunstan(at)2ndquadrant(dot)com>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, sawada(dot)mshk(at)gmail(dot)com, tgl(at)sss(dot)pgh(dot)pa(dot)us, alvherre(at)2ndquadrant(dot)com, sk(at)zsrv(dot)org, nasbyj(at)amazon(dot)com, robertmhaas(at)gmail(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: pgsql: Improve autovacuum logging for aggressive and anti-wraparound ru |
Date: | 2020-03-24 01:41:50 |
Message-ID: | 20200324014150.2nyuygbbejzaybip@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2020-03-24 01:45:24 | pgsql: Report NULL as total backup size if it's not estimated. |
Previous Message | Jeff Davis | 2020-03-23 22:45:04 | pgsql: Fixes for Disk-based Hash Aggregation. |
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2020-03-24 01:46:51 | Re: pg_stat_progress_basebackup - progress reporting for pg_basebackup, in the server side |
Previous Message | Tomas Vondra | 2020-03-24 01:08:38 | Re: Additional improvements to extended statistics |