Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit dd9ac7d

Browse files
committed
Revert "Skip redundant anti-wraparound vacuums"
This reverts commit 2aa6e33, that added a fast path to skip anti-wraparound and non-aggressive autovacuum jobs (these have no sense as anti-wraparound implies aggressive). With a cluster using a high amount of relations with a portion of them being heavily updated, this could cause autovacuum to lock down, with autovacuum workers attempting repeatedly those jobs on the same relations for the same database, that just kept being skipped. This lock down can be solved with a manual VACUUM FREEZE. Justin King has reported one environment where the issue happened, and Julien Rouhaud and I have been able to reproduce it in a second environment. With a very aggressive autovacuum_freeze_max_age, triggering those jobs with pgbench is a matter of minutes, and hitting the lock down is a lot harder (my local tests failed to do that). Note that anti-wraparound and non-aggressive jobs can only be triggered on a subset of shared catalogs: - pg_auth_members - pg_authid - pg_database - pg_replication_origin - pg_shseclabel - pg_subscription - pg_tablespace While the lock down was possible down to v12, the root cause of those jobs is a much older issue, which needs more analysis. Bonus thanks to Andres Freund for the discussion. Reported-by: Justin King Discussion: https://postgr.es/m/CAE39h22zPLrkH17GrkDgAYL3kbjvySYD1io+rtnAUFnaJJVS4g@mail.gmail.com Backpatch-through: 12
1 parent 7c2dbc6 commit dd9ac7d

File tree

1 file changed

+4
-20
lines changed

1 file changed

+4
-20
lines changed

src/backend/access/heap/vacuumlazy.c

Lines changed: 4 additions & 20 deletions
Original file line numberDiff line numberDiff line change
@@ -462,23 +462,6 @@ heap_vacuum_rel(Relation onerel, VacuumParams *params,
462462
if (params->options & VACOPT_DISABLE_PAGE_SKIPPING)
463463
aggressive = true;
464464

465-
/*
466-
* Normally the relfrozenxid for an anti-wraparound vacuum will be old
467-
* enough to force an aggressive vacuum. However, a concurrent vacuum
468-
* might have already done this work that the relfrozenxid in relcache has
469-
* been updated. If that happens this vacuum is redundant, so skip it.
470-
*/
471-
if (params->is_wraparound && !aggressive)
472-
{
473-
ereport(DEBUG1,
474-
(errmsg("skipping redundant vacuum to prevent wraparound of table \"%s.%s.%s\"",
475-
get_database_name(MyDatabaseId),
476-
get_namespace_name(RelationGetNamespace(onerel)),
477-
RelationGetRelationName(onerel))));
478-
pgstat_progress_end_command();
479-
return;
480-
}
481-
482465
vacrelstats = (LVRelStats *) palloc0(sizeof(LVRelStats));
483466

484467
vacrelstats->relnamespace = get_namespace_name(RelationGetNamespace(onerel));
@@ -639,9 +622,10 @@ heap_vacuum_rel(Relation onerel, VacuumParams *params,
639622
initStringInfo(&buf);
640623
if (params->is_wraparound)
641624
{
642-
/* an anti-wraparound vacuum has to be aggressive */
643-
Assert(aggressive);
644-
msgfmt = _("automatic aggressive vacuum to prevent wraparound of table \"%s.%s.%s\": index scans: %d\n");
625+
if (aggressive)
626+
msgfmt = _("automatic aggressive vacuum to prevent wraparound of table \"%s.%s.%s\": index scans: %d\n");
627+
else
628+
msgfmt = _("automatic vacuum to prevent wraparound of table \"%s.%s.%s\": index scans: %d\n");
645629
}
646630
else
647631
{

0 commit comments

Comments
 (0)