From f2066c8ca5ba1b6f31257a36bb3dd065ecb1e3d4 Mon Sep 17 00:00:00 2001 From: Peter Geoghegan Date: Mon, 5 Sep 2022 17:46:34 -0700 Subject: [PATCH v6 4/6] Make VACUUM's aggressive behaviors continuous. The concept of aggressive/scan_all VACUUM dates back to the introduction of the visibility map in Postgres 8.4. Before then, every lazy VACUUM was "equally aggressive": each operation froze whatever tuples before the age-wise cutoff needed to be frozen. And each table's relfrozenxid was updated at the end. In short, the previous behavior was much less efficient, but did at least have one thing going for it: it was much easier to understand at a high level. VACUUM no longer applies a separate mode of operation (aggressive mode). There are still antiwraparound autovacuums, but they're now little more than another way that autovacuum.c can launch an autovacuum worker to run VACUUM. The same set of behaviors previously associated with aggressive mode are retained, but now get applied selectively, on a timeline attuned to the needs of the table. The closer that a table's age gets to the autovacuum_freeze_max_age cutoff, the less VACUUM will care about avoiding the cost of scanning extra pages to advance relfrozenxid "early". This new approach cares about both costs (extra pages scanned) and benefits (the need for relfrozenxid advancements), unlike the previous approach driven by vacuum_freeze_table_age, which "escalated to aggressive mode" purely based on a simple XID age cutoff. The vacuum_freeze_table_age GUC is now relegated to a compatibility option. Its default value is now -1, which is interpreted as "current value of autovacuum_freeze_max_age". VACUUM will still advance relfrozenxid at roughly the same XID-age-wise cadence as before with static tables, but can also advance relfrozenxid much more frequently in tables where that happens to make sense. In practice many tables will tend to have relfrozenxid advanced by some amount during every VACUUM, especially larger tables and very small tables. The emphasis is now on keeping each table's age reasonably recent over time, across multiple successive VACUUM operations, while spreading out the burden of freezing, avoiding big spikes. Freezing is now primarily treated as an overhead of long term storage of tuples in physical heap pages. There is less emphasis on the role freezing plays in preventing the system from reaching the point of an xidStopLimit outage. Now every VACUUM might need to wait for a cleanup lock, though few will. It can only happen when required to advance relfrozenxid to no less than half way between the existing relfrozenxid and nextXID. In general there is no telling how long VACUUM might spend waiting for a cleanup lock, so it's usually more useful to focus on keeping up with freezing at the level of the whole table. VACUUM can afford to set relfrozenxid to a significantly older value in the short term, since there are now more opportunities to advance relfrozenxid in the long term. --- src/include/commands/vacuum.h | 7 +- src/backend/access/heap/vacuumlazy.c | 223 +++--- src/backend/access/transam/multixact.c | 5 +- src/backend/commands/cluster.c | 10 +- src/backend/commands/vacuum.c | 113 +-- src/backend/utils/activity/pgstat_relation.c | 4 +- src/backend/utils/misc/guc_tables.c | 8 +- src/backend/utils/misc/postgresql.conf.sample | 4 +- doc/src/sgml/config.sgml | 103 +-- doc/src/sgml/logicaldecoding.sgml | 2 +- doc/src/sgml/maintenance.sgml | 721 ++++++++---------- doc/src/sgml/ref/create_table.sgml | 2 +- doc/src/sgml/ref/prepare_transaction.sgml | 2 +- doc/src/sgml/ref/vacuum.sgml | 27 +- doc/src/sgml/ref/vacuumdb.sgml | 4 +- .../expected/vacuum-no-cleanup-lock.out | 24 +- .../specs/vacuum-no-cleanup-lock.spec | 30 +- src/test/regress/expected/reloptions.out | 6 +- src/test/regress/sql/reloptions.sql | 6 +- 19 files changed, 638 insertions(+), 663 deletions(-) diff --git a/src/include/commands/vacuum.h b/src/include/commands/vacuum.h index 52379f819..a70df0218 100644 --- a/src/include/commands/vacuum.h +++ b/src/include/commands/vacuum.h @@ -290,7 +290,7 @@ extern void vac_update_relstats(Relation relation, bool *frozenxid_updated, bool *minmulti_updated, bool in_outer_xact); -extern bool vacuum_set_xid_limits(Relation rel, +extern void vacuum_set_xid_limits(Relation rel, int freeze_min_age, int multixact_freeze_min_age, int freeze_table_age, @@ -298,7 +298,10 @@ extern bool vacuum_set_xid_limits(Relation rel, TransactionId *oldestXmin, MultiXactId *oldestMxact, TransactionId *freezeLimit, - MultiXactId *multiXactCutoff); + MultiXactId *multiXactCutoff, + TransactionId *minXid, + MultiXactId *minMulti, + double *antiwrapfrac); extern bool vacuum_xid_failsafe_check(TransactionId relfrozenxid, MultiXactId relminmxid); extern void vac_update_datfrozenxid(void); diff --git a/src/backend/access/heap/vacuumlazy.c b/src/backend/access/heap/vacuumlazy.c index 278833077..97f3b83ac 100644 --- a/src/backend/access/heap/vacuumlazy.c +++ b/src/backend/access/heap/vacuumlazy.c @@ -109,10 +109,11 @@ ((BlockNumber) (((uint64) 8 * 1024 * 1024 * 1024) / BLCKSZ)) /* - * Threshold that controls whether non-aggressive VACUUMs will skip any - * all-visible pages when using the lazy freezing strategy + * Thresholds that control whether VACUUM will skip any all-visible pages when + * using the lazy freezing strategy */ #define SKIPALLVIS_THRESHOLD_PAGES 0.05 /* i.e. 5% of rel_pages */ +#define SKIPALLVIS_MIDPOINT_THRESHOLD_PAGES 0.15 /* * Size of the prefetch window for lazy vacuum backwards truncation scan. @@ -144,9 +145,7 @@ typedef struct LVRelState Relation *indrels; int nindexes; - /* Aggressive VACUUM? (must set relfrozenxid >= FreezeLimit) */ - bool aggressive; - /* Skip (don't scan) all-visible pages? (must be !aggressive) */ + /* Skip (don't scan) all-visible pages? */ bool skipallvis; /* Skip (don't scan) all-frozen pages? */ bool skipallfrozen; @@ -178,6 +177,9 @@ typedef struct LVRelState /* Limits on the age of the oldest unfrozen XID and MXID */ TransactionId FreezeLimit; MultiXactId MultiXactCutoff; + /* Earliest permissible NewRelfrozenXid/NewRelminMxid values */ + TransactionId MinXid; + MultiXactId MinMulti; /* Tracks oldest extant XID/MXID for setting relfrozenxid/relminmxid */ TransactionId NewRelfrozenXid; MultiXactId NewRelminMxid; @@ -258,7 +260,8 @@ static void lazy_scan_heap(LVRelState *vacrel); static BlockNumber lazy_scan_strategy(LVRelState *vacrel, BlockNumber eager_threshold, BlockNumber all_visible, - BlockNumber all_frozen); + BlockNumber all_frozen, + double antiwrapfrac); static BlockNumber lazy_scan_skip(LVRelState *vacrel, BlockNumber next_block, bool *all_visible); static bool lazy_scan_new_or_empty(LVRelState *vacrel, Buffer buf, @@ -322,13 +325,15 @@ heap_vacuum_rel(Relation rel, VacuumParams *params, LVRelState *vacrel; bool verbose, instrument, - aggressive, frozenxid_updated, minmulti_updated; TransactionId OldestXmin, - FreezeLimit; + FreezeLimit, + MinXid; MultiXactId OldestMxact, - MultiXactCutoff; + MultiXactCutoff, + MinMulti; + double antiwrapfrac; BlockNumber orig_rel_pages, eager_threshold, all_visible, @@ -367,33 +372,33 @@ heap_vacuum_rel(Relation rel, VacuumParams *params, /* * Get OldestXmin cutoff, which is used to determine which deleted tuples * are considered DEAD, not just RECENTLY_DEAD. Also get related cutoffs - * used to determine which XIDs/MultiXactIds will be frozen. If this is - * an aggressive VACUUM then lazy_scan_heap cannot leave behind unfrozen - * XIDs < FreezeLimit (all MXIDs < MultiXactCutoff also need to go away). + * used to determine which XIDs/MultiXactIds will be frozen. * * Also determine our cutoff for applying the eager/all-visible freezing - * strategy. If rel_pages is larger than this cutoff we use the strategy, - * even during non-aggressive VACUUMs. + * strategy. If rel_pages is larger than this cutoff we use the strategy. */ - aggressive = vacuum_set_xid_limits(rel, - params->freeze_min_age, - params->multixact_freeze_min_age, - params->freeze_table_age, - params->multixact_freeze_table_age, - &OldestXmin, &OldestMxact, - &FreezeLimit, &MultiXactCutoff); + vacuum_set_xid_limits(rel, + params->freeze_min_age, + params->multixact_freeze_min_age, + params->freeze_table_age, + params->multixact_freeze_table_age, + &OldestXmin, &OldestMxact, + &FreezeLimit, &MultiXactCutoff, + &MinXid, &MinMulti, &antiwrapfrac); eager_threshold = params->freeze_strategy_threshold < 0 ? vacuum_freeze_strategy_threshold : params->freeze_strategy_threshold; - if (params->options & VACOPT_DISABLE_PAGE_SKIPPING) - { - /* - * Force aggressive mode, and disable skipping blocks using the - * visibility map (even those set all-frozen) - */ - aggressive = true; - } + /* + * Make sure that antiwraparound autovacuums always have the opportunity + * to advance relfrozenxid to a value >= MinXid. + * + * This is needed so that antiwraparound autovacuums reliably advance + * relfrozenxid to the satisfaction of autovacuum.c, even when the + * autovacuum_freeze_max_age reloption (not GUC) triggered the autovacuum. + */ + if (params->is_wraparound) + antiwrapfrac = 1.0; /* * Setup error traceback support for ereport() first. The idea is to set @@ -442,10 +447,9 @@ heap_vacuum_rel(Relation rel, VacuumParams *params, Assert(params->index_cleanup != VACOPTVALUE_UNSPECIFIED); Assert(params->truncate != VACOPTVALUE_UNSPECIFIED && params->truncate != VACOPTVALUE_AUTO); - vacrel->aggressive = aggressive; /* Initialize skipallvis/skipallfrozen before lazy_scan_strategy call */ - vacrel->skipallvis = !aggressive; - vacrel->skipallfrozen = (params->options & VACOPT_DISABLE_PAGE_SKIPPING) == 0; + vacrel->skipallvis = (params->options & VACOPT_DISABLE_PAGE_SKIPPING) == 0; + vacrel->skipallfrozen = vacrel->skipallvis; vacrel->failsafe_active = false; vacrel->consider_bypass_optimization = true; vacrel->do_index_vacuuming = true; @@ -515,6 +519,10 @@ heap_vacuum_rel(Relation rel, VacuumParams *params, vacrel->FreezeLimit = FreezeLimit; /* MultiXactCutoff controls MXID freezing (always <= OldestMxact) */ vacrel->MultiXactCutoff = MultiXactCutoff; + /* MinXid limits final relfrozenxid's age (always <= FreezeLimit) */ + vacrel->MinXid = MinXid; + /* MinMulti limits final relminmxid's age (always <= MultiXactCutoff) */ + vacrel->MinMulti = MinMulti; /* Initialize state used to track oldest extant XID/MXID */ vacrel->NewRelfrozenXid = OldestXmin; vacrel->NewRelminMxid = OldestMxact; @@ -538,7 +546,8 @@ heap_vacuum_rel(Relation rel, VacuumParams *params, vacrel->vmsnap = visibilitymap_snap(rel, orig_rel_pages, &all_visible, &all_frozen); scanned_pages = lazy_scan_strategy(vacrel, eager_threshold, - all_visible, all_frozen); + all_visible, all_frozen, + antiwrapfrac); if (verbose) ereport(INFO, (errmsg("vacuuming \"%s.%s.%s\"", @@ -599,25 +608,19 @@ heap_vacuum_rel(Relation rel, VacuumParams *params, /* * Prepare to update rel's pg_class entry. * - * Aggressive VACUUMs must always be able to advance relfrozenxid to a - * value >= FreezeLimit, and relminmxid to a value >= MultiXactCutoff. - * Non-aggressive VACUUMs may advance them by any amount, or not at all. + * VACUUM can only advance relfrozenxid to a value >= MinXid, and + * relminmxid to a value >= MinMulti. */ Assert(vacrel->NewRelfrozenXid == OldestXmin || - TransactionIdPrecedesOrEquals(aggressive ? FreezeLimit : - vacrel->relfrozenxid, - vacrel->NewRelfrozenXid)); + TransactionIdPrecedesOrEquals(MinXid, vacrel->NewRelfrozenXid)); Assert(vacrel->NewRelminMxid == OldestMxact || - MultiXactIdPrecedesOrEquals(aggressive ? MultiXactCutoff : - vacrel->relminmxid, - vacrel->NewRelminMxid)); + MultiXactIdPrecedesOrEquals(MinMulti, vacrel->NewRelminMxid)); if (vacrel->skipallvis) { /* - * Must keep original relfrozenxid in a non-aggressive VACUUM whose - * lazy_scan_strategy call determined it would skip all-visible pages + * Must keep original relfrozenxid when lazy_scan_strategy call + * decided to skip all-visible pages */ - Assert(!aggressive); vacrel->NewRelfrozenXid = InvalidTransactionId; vacrel->NewRelminMxid = InvalidMultiXactId; } @@ -693,23 +696,11 @@ heap_vacuum_rel(Relation rel, VacuumParams *params, Assert(!params->is_wraparound); msgfmt = _("finished vacuuming \"%s.%s.%s\": index scans: %d\n"); } - else if (params->is_wraparound) - { - /* - * While it's possible for a VACUUM to be both is_wraparound - * and !aggressive, that's just a corner-case -- is_wraparound - * implies aggressive. Produce distinct output for the corner - * case all the same, just in case. - */ - if (aggressive) - msgfmt = _("automatic aggressive vacuum to prevent wraparound of table \"%s.%s.%s\": index scans: %d\n"); - else - msgfmt = _("automatic vacuum to prevent wraparound of table \"%s.%s.%s\": index scans: %d\n"); - } else { - if (aggressive) - msgfmt = _("automatic aggressive vacuum of table \"%s.%s.%s\": index scans: %d\n"); + Assert(IsAutoVacuumWorkerProcess()); + if (params->is_wraparound) + msgfmt = _("automatic vacuum to prevent wraparound of table \"%s.%s.%s\": index scans: %d\n"); else msgfmt = _("automatic vacuum of table \"%s.%s.%s\": index scans: %d\n"); } @@ -1041,7 +1032,6 @@ lazy_scan_heap(LVRelState *vacrel) * lazy_scan_noprune could not do all required processing. Wait * for a cleanup lock, and call lazy_scan_prune in the usual way. */ - Assert(vacrel->aggressive); LockBuffer(buf, BUFFER_LOCK_UNLOCK); LockBufferForCleanup(buf); } @@ -1300,21 +1290,19 @@ lazy_scan_heap(LVRelState *vacrel) * On the other hand we eagerly freeze pages when that strategy spreads out * the burden of freezing over time. Performance stability is important; no * one VACUUM operation should need to freeze disproportionately many pages. - * Antiwraparound VACUUMs of append-only tables should generally be avoided. * * Also determines if the ongoing VACUUM operation should skip all-visible - * pages for non-aggressive VACUUMs, where advancing relfrozenxid is optional. - * When VACUUM freezes eagerly it always also scans pages eagerly, since it's - * important that relfrozenxid advance in affected tables, which are larger. - * When VACUUM freezes lazily it might make sense to scan pages lazily (skip - * all-visible pages) or eagerly (be capable of relfrozenxid advancement), - * depending on the extra cost - we might need to scan only a few extra pages. + * pages when advancing relfrozenxid is still optional (before target rel has + * attained an age that forces an antiwraparound autovacuum). Decision is + * based in part on caller's antiwrapfrac argument, which represents how close + * the table age is to forcing antiwraparound autovacuum. * * Returns final scanned_pages for the VACUUM operation. */ static BlockNumber lazy_scan_strategy(LVRelState *vacrel, BlockNumber eager_threshold, - BlockNumber all_visible, BlockNumber all_frozen) + BlockNumber all_visible, BlockNumber all_frozen, + double antiwrapfrac) { BlockNumber rel_pages = vacrel->rel_pages, scanned_pages_skipallvis, @@ -1357,21 +1345,15 @@ lazy_scan_strategy(LVRelState *vacrel, BlockNumber eager_threshold, if (!vacrel->skipallfrozen) { /* DISABLE_PAGE_SKIPPING makes all skipping unsafe */ - Assert(vacrel->aggressive && !vacrel->skipallvis); - vacrel->allvis_freeze_strategy = true; - return rel_pages; - } - else if (vacrel->aggressive) - { - /* Always freeze all-visible pages during aggressive VACUUMs */ Assert(!vacrel->skipallvis); vacrel->allvis_freeze_strategy = true; + return rel_pages; } else if (rel_pages >= eager_threshold) { /* - * Non-aggressive VACUUM of table whose rel_pages now exceeds - * GUC-based threshold for eager freezing. + * VACUUM of table whose rel_pages now exceeds GUC-based threshold for + * eager freezing. * * We always scan all-visible pages when the threshold is crossed, so * that relfrozenxid can be advanced. There will typically be few or @@ -1386,9 +1368,6 @@ lazy_scan_strategy(LVRelState *vacrel, BlockNumber eager_threshold, BlockNumber nextra, nextra_threshold; - /* Non-aggressive VACUUM of small table -- use lazy freeze strategy */ - vacrel->allvis_freeze_strategy = false; - /* * Decide on whether or not we'll skip all-visible pages. * @@ -1402,13 +1381,44 @@ lazy_scan_strategy(LVRelState *vacrel, BlockNumber eager_threshold, * that way, so be lazy (just skip) unless the added cost is very low. * We opt for a skipallfrozen-only VACUUM when the number of extra * pages (extra scanned pages that are all-visible but not all-frozen) - * is less than 5% of rel_pages (or 32 pages when rel_pages is small). + * is less than 5% of rel_pages (or 32 pages when rel_pages is small) + * if relfrozenxid has yet to attain an age that uses 50% of the XID + * space available before the GUC cutoff for antiwraparound + * autovacuum. A more aggressive threshold of 15% is used when + * relfrozenxid is older than that. */ nextra = scanned_pages_skipallfrozen - scanned_pages_skipallvis; - nextra_threshold = (double) rel_pages * SKIPALLVIS_THRESHOLD_PAGES; + + if (antiwrapfrac < 0.5) + nextra_threshold = (double) rel_pages * + SKIPALLVIS_THRESHOLD_PAGES; + else + nextra_threshold = (double) rel_pages * + SKIPALLVIS_MIDPOINT_THRESHOLD_PAGES; + nextra_threshold = Max(32, nextra_threshold); - vacrel->skipallvis = nextra >= nextra_threshold; + /* + * We must advance relfrozenxid when it already attained an age that + * consumes >= 90% of the available XID space (or MXID space) before + * the crossover point for antiwraparound autovacuum. + * + * Also use eager freezing strategy when we're past the "90% towards + * wraparound" point, even though the table size is below the usual + * eager_threshold table size cutoff. The added cost is usually not + * too great. We may be able to fall into a pattern of continually + * advancing relfrozenxid this way. + */ + if (antiwrapfrac < 0.9) + { + vacrel->skipallvis = nextra >= nextra_threshold; + vacrel->allvis_freeze_strategy = false; + } + else + { + vacrel->skipallvis = false; + vacrel->allvis_freeze_strategy = true; + } } /* Return the appropriate variant of scanned_pages */ @@ -2023,11 +2033,9 @@ retry: * operation left LP_DEAD items behind. We'll at least collect any such items * in the dead_items array for removal from indexes. * - * For aggressive VACUUM callers, we may return false to indicate that a full - * cleanup lock is required for processing by lazy_scan_prune. This is only - * necessary when the aggressive VACUUM needs to freeze some tuple XIDs from - * one or more tuples on the page. We always return true for non-aggressive - * callers. + * We may return false to indicate that a full cleanup lock is required for + * processing by lazy_scan_prune. This is only necessary when VACUUM needs to + * freeze some tuple XIDs from one or more tuples on the page. * * See lazy_scan_prune for an explanation of hastup return flag. * recordfreespace flag instructs caller on whether or not it should do @@ -2095,36 +2103,23 @@ lazy_scan_noprune(LVRelState *vacrel, *hastup = true; /* page prevents rel truncation */ tupleheader = (HeapTupleHeader) PageGetItem(page, itemid); if (heap_tuple_would_freeze(tupleheader, - vacrel->FreezeLimit, - vacrel->MultiXactCutoff, + vacrel->MinXid, vacrel->MinMulti, &NewRelfrozenXid, &NewRelminMxid)) { - /* Tuple with XID < FreezeLimit (or MXID < MultiXactCutoff) */ - if (vacrel->aggressive) - { - /* - * Aggressive VACUUMs must always be able to advance rel's - * relfrozenxid to a value >= FreezeLimit (and be able to - * advance rel's relminmxid to a value >= MultiXactCutoff). - * The ongoing aggressive VACUUM won't be able to do that - * unless it can freeze an XID (or MXID) from this tuple now. - * - * The only safe option is to have caller perform processing - * of this page using lazy_scan_prune. Caller might have to - * wait a while for a cleanup lock, but it can't be helped. - */ - vacrel->offnum = InvalidOffsetNumber; - return false; - } - /* - * Non-aggressive VACUUMs are under no obligation to advance - * relfrozenxid (even by one XID). We can be much laxer here. + * Tuple with XID < MinXid (or MXID < MinMulti) * - * Currently we always just accept an older final relfrozenxid - * and/or relminmxid value. We never make caller wait or work a - * little harder, even when it likely makes sense to do so. + * VACUUM must always be able to advance rel's relfrozenxid and + * relminmxid to minimum values. The ongoing VACUUM won't be able + * to do that unless it can freeze an XID (or MXID) from this + * tuple now. + * + * The only safe option is to have caller perform processing of + * this page using lazy_scan_prune. Caller might have to wait a + * while for a cleanup lock, but it can't be helped. */ + vacrel->offnum = InvalidOffsetNumber; + return false; } ItemPointerSet(&(tuple.t_self), blkno, offnum); diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c index 204aa9504..ba575c5fd 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2816,10 +2816,7 @@ ReadMultiXactCounts(uint32 *multixacts, MultiXactOffset *members) * freeze table and the minimum freeze age based on the effective * autovacuum_multixact_freeze_max_age this function returns. In the worst * case, we'll claim the freeze_max_age to zero, and every vacuum of any - * table will try to freeze every multixact. - * - * It's possible that these thresholds should be user-tunable, but for now - * we keep it simple. + * table will freeze every multixact. */ int MultiXactMemberFreezeThreshold(void) diff --git a/src/backend/commands/cluster.c b/src/backend/commands/cluster.c index 3b78a2f10..d2950fd6e 100644 --- a/src/backend/commands/cluster.c +++ b/src/backend/commands/cluster.c @@ -824,9 +824,12 @@ copy_table_data(Oid OIDNewHeap, Oid OIDOldHeap, Oid OIDOldIndex, bool verbose, TupleDesc oldTupDesc PG_USED_FOR_ASSERTS_ONLY; TupleDesc newTupDesc PG_USED_FOR_ASSERTS_ONLY; TransactionId OldestXmin, - FreezeXid; + FreezeXid, + MinXid; MultiXactId OldestMxact, - MultiXactCutoff; + MultiXactCutoff, + MinMulti; + double antiwrapfrac; bool use_sort; double num_tuples = 0, tups_vacuumed = 0, @@ -915,7 +918,8 @@ copy_table_data(Oid OIDNewHeap, Oid OIDOldHeap, Oid OIDOldIndex, bool verbose, * not to be aggressive about this. */ vacuum_set_xid_limits(OldHeap, 0, 0, 0, 0, &OldestXmin, &OldestMxact, - &FreezeXid, &MultiXactCutoff); + &FreezeXid, &MultiXactCutoff, &MinXid, &MinMulti, + &antiwrapfrac); /* * FreezeXid will become the table's new relfrozenxid, and that mustn't go diff --git a/src/backend/commands/vacuum.c b/src/backend/commands/vacuum.c index df2bd53b9..5bdab6eb0 100644 --- a/src/backend/commands/vacuum.c +++ b/src/backend/commands/vacuum.c @@ -943,21 +943,25 @@ get_all_vacuum_rels(int options) * - oldestMxact is the Mxid below which MultiXacts are definitely not * seen as visible by any running transaction. * - freezeLimit is the Xid below which all Xids are definitely replaced by - * FrozenTransactionId during aggressive vacuums. + * FrozenTransactionId in heap pages that caller can cleanup lock. * - multiXactCutoff is the value below which all MultiXactIds are definitely - * removed from Xmax during aggressive vacuums. + * removed from Xmax in heap pages that caller can cleanup lock. + * - minXid is the earliest valid relfrozenxid value to set in pg_class. + * - minMulti is the earliest valid relminmxid value to set in pg_class. + * - antiwrapfrac is how close the table's age is to the point that autovacuum + * will launch an antiwraparound autovacuum worker. * - * Return value indicates if vacuumlazy.c caller should make its VACUUM - * operation aggressive. An aggressive VACUUM must advance relfrozenxid up to - * FreezeLimit (at a minimum), and relminmxid up to multiXactCutoff (at a - * minimum). + * The antiwrapfrac value 1.0 represents the point that autovacuum.c + * scheduling considers advancing relfrozenxid strictly necessary. Values + * between 0.0 and 1.0 represent how close the table is to the point of + * mandatory relfrozenxid/relminmxid advancement (up to minXid/minMulti). * * oldestXmin and oldestMxact are the most recent values that can ever be * passed to vac_update_relstats() as frozenxid and minmulti arguments by our * vacuumlazy.c caller later on. These values should be passed when it turns * out that VACUUM will leave no unfrozen XIDs/MXIDs behind in the table. */ -bool +void vacuum_set_xid_limits(Relation rel, int freeze_min_age, int multixact_freeze_min_age, @@ -966,15 +970,20 @@ vacuum_set_xid_limits(Relation rel, TransactionId *oldestXmin, MultiXactId *oldestMxact, TransactionId *freezeLimit, - MultiXactId *multiXactCutoff) + MultiXactId *multiXactCutoff, + TransactionId *minXid, + MultiXactId *minMulti, + double *antiwrapfrac) { TransactionId nextXID, - safeOldestXmin, - aggressiveXIDCutoff; + safeOldestXmin; MultiXactId nextMXID, - safeOldestMxact, - aggressiveMXIDCutoff; - int effective_multixact_freeze_max_age; + safeOldestMxact; + double XIDFrac, + MXIDFrac; + int effective_multixact_freeze_max_age, + relfrozenxid_age, + relminmxid_age; /* * Acquire oldestXmin. @@ -1065,8 +1074,8 @@ vacuum_set_xid_limits(Relation rel, *multiXactCutoff = *oldestMxact; /* - * Done setting output parameters; check if oldestXmin or oldestMxact are - * held back to an unsafe degree in passing + * Check if oldestXmin or oldestMxact are held back to an unsafe degree in + * passing */ safeOldestXmin = nextXID - autovacuum_freeze_max_age; if (!TransactionIdIsNormal(safeOldestXmin)) @@ -1086,48 +1095,64 @@ vacuum_set_xid_limits(Relation rel, "You might also need to commit or roll back old prepared transactions, or drop stale replication slots."))); /* - * Finally, figure out if caller needs to do an aggressive VACUUM or not. + * Work out how close we are to needing an antiwraparound VACUUM. * * Determine the table freeze age to use: as specified by the caller, or - * the value of the vacuum_freeze_table_age GUC, but in any case not more - * than autovacuum_freeze_max_age * 0.95, so that if you have e.g nightly - * VACUUM schedule, the nightly VACUUM gets a chance to freeze XIDs before - * anti-wraparound autovacuum is launched. + * the value of the vacuum_freeze_table_age GUC. The GUC's default value + * of -1 is interpreted as "just use autovacuum_freeze_max_age value". + * Also clamp using autovacuum_freeze_max_age. */ if (freeze_table_age < 0) freeze_table_age = vacuum_freeze_table_age; - freeze_table_age = Min(freeze_table_age, autovacuum_freeze_max_age * 0.95); - Assert(freeze_table_age >= 0); - aggressiveXIDCutoff = nextXID - freeze_table_age; - if (!TransactionIdIsNormal(aggressiveXIDCutoff)) - aggressiveXIDCutoff = FirstNormalTransactionId; - if (TransactionIdPrecedesOrEquals(rel->rd_rel->relfrozenxid, - aggressiveXIDCutoff)) - return true; + if (freeze_table_age < 0 || freeze_table_age > autovacuum_freeze_max_age) + freeze_table_age = autovacuum_freeze_max_age; /* * Similar to the above, determine the table freeze age to use for * multixacts: as specified by the caller, or the value of the - * vacuum_multixact_freeze_table_age GUC, but in any case not more than - * effective_multixact_freeze_max_age * 0.95, so that if you have e.g. - * nightly VACUUM schedule, the nightly VACUUM gets a chance to freeze - * multixacts before anti-wraparound autovacuum is launched. + * vacuum_multixact_freeze_table_age GUC. The GUC's default value of -1 + * is interpreted as "just use effective_multixact_freeze_max_age value". + * Also clamp using effective_multixact_freeze_max_age. */ if (multixact_freeze_table_age < 0) multixact_freeze_table_age = vacuum_multixact_freeze_table_age; - multixact_freeze_table_age = - Min(multixact_freeze_table_age, - effective_multixact_freeze_max_age * 0.95); - Assert(multixact_freeze_table_age >= 0); - aggressiveMXIDCutoff = nextMXID - multixact_freeze_table_age; - if (aggressiveMXIDCutoff < FirstMultiXactId) - aggressiveMXIDCutoff = FirstMultiXactId; - if (MultiXactIdPrecedesOrEquals(rel->rd_rel->relminmxid, - aggressiveMXIDCutoff)) - return true; + if (multixact_freeze_table_age < 0 || + multixact_freeze_table_age > effective_multixact_freeze_max_age) + multixact_freeze_table_age = effective_multixact_freeze_max_age; - /* Non-aggressive VACUUM */ - return false; + /* Final antiwrapfrac can come from either XID or MXID table age */ + relfrozenxid_age = Max(nextXID - rel->rd_rel->relfrozenxid, 1); + relminmxid_age = Max(nextMXID - rel->rd_rel->relminmxid, 1); + freeze_table_age = Max(freeze_table_age, 1); + multixact_freeze_table_age = Max(multixact_freeze_table_age, 1); + XIDFrac = (double) relfrozenxid_age / (double) freeze_table_age; + MXIDFrac = (double) relminmxid_age / (double) multixact_freeze_table_age; + *antiwrapfrac = Max(XIDFrac, MXIDFrac); + + /* + * Pages that caller can cleanup lock immediately will never be left with + * XIDs < freezeLimit (nor with MXIDs < multiXactCutoff). Determine + * values for a distinct set of cutoffs applied to pages that cannot be + * immediately cleanup locked. The cutoffs govern caller's wait behavior. + * + * It is safer to accept earlier final relfrozenxid and relminmxid values + * than it would be to wait indefinitely for a cleanup lock. Waiting for + * a cleanup lock to freeze one heap page risks not freezing every other + * eligible heap page. Keeping up the momentum is what matters most. + */ + *minXid = nextXID - (freeze_table_age / 2); + if (!TransactionIdIsNormal(*minXid)) + *minXid = FirstNormalTransactionId; + /* minXid must always be <= freezeLimit */ + if (TransactionIdPrecedes(*freezeLimit, *minXid)) + *minXid = *freezeLimit; + + *minMulti = nextMXID - (multixact_freeze_table_age / 2); + if (*minMulti < FirstMultiXactId) + *minMulti = FirstMultiXactId; + /* minMulti must always be <= multiXactCutoff */ + if (MultiXactIdPrecedes(*multiXactCutoff, *minMulti)) + *minMulti = *multiXactCutoff; } /* diff --git a/src/backend/utils/activity/pgstat_relation.c b/src/backend/utils/activity/pgstat_relation.c index 55a355f58..b586b4aff 100644 --- a/src/backend/utils/activity/pgstat_relation.c +++ b/src/backend/utils/activity/pgstat_relation.c @@ -234,8 +234,8 @@ pgstat_report_vacuum(Oid tableoid, bool shared, tabentry->n_dead_tuples = deadtuples; /* - * It is quite possible that a non-aggressive VACUUM ended up skipping - * various pages, however, we'll zero the insert counter here regardless. + * It is quite possible that VACUUM will skip all-visible pages for a + * smaller table, however, we'll zero the insert counter here regardless. * It's currently used only to track when we need to perform an "insert" * autovacuum, which are mainly intended to freeze newly inserted tuples. * Zeroing this may just mean we'll not try to vacuum the table again diff --git a/src/backend/utils/misc/guc_tables.c b/src/backend/utils/misc/guc_tables.c index 5ca4a71d7..4dd70c334 100644 --- a/src/backend/utils/misc/guc_tables.c +++ b/src/backend/utils/misc/guc_tables.c @@ -2456,10 +2456,10 @@ struct config_int ConfigureNamesInt[] = { {"vacuum_freeze_table_age", PGC_USERSET, CLIENT_CONN_STATEMENT, gettext_noop("Age at which VACUUM should scan whole table to freeze tuples."), - NULL + gettext_noop("-1 to use autovacuum_freeze_max_age value.") }, &vacuum_freeze_table_age, - 150000000, 0, 2000000000, + -1, -1, 2000000000, NULL, NULL, NULL }, @@ -2476,10 +2476,10 @@ struct config_int ConfigureNamesInt[] = { {"vacuum_multixact_freeze_table_age", PGC_USERSET, CLIENT_CONN_STATEMENT, gettext_noop("Multixact age at which VACUUM should scan whole table to freeze tuples."), - NULL + gettext_noop("-1 to use autovacuum_multixact_freeze_max_age value.") }, &vacuum_multixact_freeze_table_age, - 150000000, 0, 2000000000, + -1, -1, 2000000000, NULL, NULL, NULL }, diff --git a/src/backend/utils/misc/postgresql.conf.sample b/src/backend/utils/misc/postgresql.conf.sample index a409e6281..544dcf57d 100644 --- a/src/backend/utils/misc/postgresql.conf.sample +++ b/src/backend/utils/misc/postgresql.conf.sample @@ -692,11 +692,11 @@ #lock_timeout = 0 # in milliseconds, 0 is disabled #idle_in_transaction_session_timeout = 0 # in milliseconds, 0 is disabled #idle_session_timeout = 0 # in milliseconds, 0 is disabled -#vacuum_freeze_table_age = 150000000 +#vacuum_freeze_table_age = -1 #vacuum_freeze_strategy_threshold = 4GB #vacuum_freeze_min_age = 50000000 #vacuum_failsafe_age = 1600000000 -#vacuum_multixact_freeze_table_age = 150000000 +#vacuum_multixact_freeze_table_age = -1 #vacuum_multixact_freeze_min_age = 5000000 #vacuum_multixact_failsafe_age = 1600000000 #bytea_output = 'hex' # hex, escape diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml index 109cc4727..4e39a42fe 100644 --- a/doc/src/sgml/config.sgml +++ b/doc/src/sgml/config.sgml @@ -8215,7 +8215,7 @@ COPY postgres_log FROM '/full/path/to/logfile.csv' WITH csv; Note that even when this parameter is disabled, the system will launch autovacuum processes if necessary to prevent transaction ID wraparound. See for more information. + linkend="vacuum-xid-space"/> for more information. @@ -8404,7 +8404,7 @@ COPY postgres_log FROM '/full/path/to/logfile.csv' WITH csv; This parameter can only be set at server start, but the setting can be reduced for individual tables by changing table storage parameters. - For more information see . + For more information see . @@ -9120,31 +9120,6 @@ COPY postgres_log FROM '/full/path/to/logfile.csv' WITH csv; - - vacuum_freeze_table_age (integer) - - vacuum_freeze_table_age configuration parameter - - - - - VACUUM performs an aggressive scan if the table's - pg_class.relfrozenxid field has reached - the age specified by this setting. An aggressive scan differs from - a regular VACUUM in that it visits every page that might - contain unfrozen XIDs or MXIDs, not just those that might contain dead - tuples. The default is 150 million transactions. Although users can - set this value anywhere from zero to two billion, VACUUM - will silently limit the effective value to 95% of - , so that a - periodic manual VACUUM has a chance to run before an - anti-wraparound autovacuum is launched for the table. For more - information see - . - - - - vacuum_freeze_strategy_threshold (integer) @@ -9160,6 +9135,39 @@ COPY postgres_log FROM '/full/path/to/logfile.csv' WITH csv; + + vacuum_freeze_table_age (integer) + + vacuum_freeze_table_age configuration parameter + + + + + VACUUM reliably advances + relfrozenxid to a recent value if + the table's + pg_class.relfrozenxid + field has reached the age specified by this setting. + The default is -1. If -1 is specified, the value + of is used. + Although users can set this value anywhere from zero to two + billion, VACUUM will silently limit the + effective value to . For more + information see . + + + + The meaning of this parameter, and its default value, changed + in PostgreSQL 16. Freezing and advancing + pg_class.relfrozenxid + now take place more proactively, in every + VACUUM operation. + + + + + vacuum_freeze_min_age (integer) @@ -9179,7 +9187,7 @@ COPY postgres_log FROM '/full/path/to/logfile.csv' WITH csv; the value of , so that there is not an unreasonably short time between forced autovacuums. For more information see . + linkend="vacuum-xid-space"/>. @@ -9225,19 +9233,27 @@ COPY postgres_log FROM '/full/path/to/logfile.csv' WITH csv; - VACUUM performs an aggressive scan if the table's - pg_class.relminmxid field has reached - the age specified by this setting. An aggressive scan differs from - a regular VACUUM in that it visits every page that might - contain unfrozen XIDs or MXIDs, not just those that might contain dead - tuples. The default is 150 million multixacts. - Although users can set this value anywhere from zero to two billion, - VACUUM will silently limit the effective value to 95% of - , so that a - periodic manual VACUUM has a chance to run before an - anti-wraparound is launched for the table. - For more information see . + VACUUM reliably advances + relminmxid to a recent value if the table's + pg_class.relminmxid + field has reached the age specified by this setting. + The default is -1. If -1 is specified, the value of is used. + Although users can set this value anywhere from zero to two + billion, VACUUM will silently limit the + effective value to . For more + information see . + + + The meaning of this parameter, and its default value, changed + in PostgreSQL 16. Freezing and advancing + pg_class.relminmxid + now take place more proactively, in every + VACUUM operation. + + @@ -9249,10 +9265,9 @@ COPY postgres_log FROM '/full/path/to/logfile.csv' WITH csv; - Specifies the cutoff age (in multixacts) that - VACUUM should use to decide whether to - trigger freezing of pages with an older multixact ID. The - default is 5 million multixacts. + Specifies the cutoff age (in multixacts) that VACUUM + should use to decide whether to trigger freezing of pages with + an older multixact ID. The default is 5 million multixacts. Although users can set this value anywhere from zero to one billion, VACUUM will silently limit the effective value to half the value of , diff --git a/doc/src/sgml/logicaldecoding.sgml b/doc/src/sgml/logicaldecoding.sgml index 38ee69dcc..380da3c1e 100644 --- a/doc/src/sgml/logicaldecoding.sgml +++ b/doc/src/sgml/logicaldecoding.sgml @@ -324,7 +324,7 @@ postgres=# select * from pg_logical_slot_get_changes('regression_slot', NULL, NU because neither required WAL nor required rows from the system catalogs can be removed by VACUUM as long as they are required by a replication slot. In extreme cases this could cause the database to shut down to prevent - transaction ID wraparound (see ). + transaction ID wraparound (see ). So if a slot is no longer required it should be dropped. diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 554b3a75d..ed54a2988 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -400,202 +400,73 @@ - - Preventing Transaction ID Wraparound Failures + + Freezing tuples - - transaction ID - wraparound - + + VACUUM freezes a page's tuples (by processing + the tuple header fields described in ) as a way of avoiding long term + dependencies on transaction status metadata referenced therein. + Heap pages that only contain frozen tuples are suitable for long + term storage. Larger databases are often mostly comprised of cold + data that is modified very infrequently, plus a relatively small + amount of hot data that is updated far more frequently. + VACUUM applies a variety of techniques that + allow it to concentrate most of its efforts on hot data. + + + + Managing the 32-bit Transaction ID address space wraparound of transaction IDs - - PostgreSQL's - MVCC transaction semantics - depend on being able to compare transaction ID (XID) - numbers: a row version with an insertion XID greater than the current - transaction's XID is in the future and should not be visible - to the current transaction. But since transaction IDs have limited size - (32 bits) a cluster that runs for a long time (more - than 4 billion transactions) would suffer transaction ID - wraparound: the XID counter wraps around to zero, and all of a sudden - transactions that were in the past appear to be in the future — which - means their output become invisible. In short, catastrophic data loss. - (Actually the data is still there, but that's cold comfort if you cannot - get at it.) To avoid this, it is necessary to vacuum every table - in every database at least once every two billion transactions. - - - - The reason that periodic vacuuming solves the problem is that - VACUUM will mark rows as frozen, indicating that - they were inserted by a transaction that committed sufficiently far in - the past that the effects of the inserting transaction are certain to be - visible to all current and future transactions. - Normal XIDs are - compared using modulo-232 arithmetic. This means - that for every normal XID, there are two billion XIDs that are - older and two billion that are newer; another - way to say it is that the normal XID space is circular with no - endpoint. Therefore, once a row version has been created with a particular - normal XID, the row version will appear to be in the past for - the next two billion transactions, no matter which normal XID we are - talking about. If the row version still exists after more than two billion - transactions, it will suddenly appear to be in the future. To - prevent this, PostgreSQL reserves a special XID, - FrozenTransactionId, which does not follow the normal XID - comparison rules and is always considered older - than every normal XID. - Frozen row versions are treated as if the inserting XID were - FrozenTransactionId, so that they will appear to be - in the past to all normal transactions regardless of wraparound - issues, and so such row versions will be valid until deleted, no matter - how long that is. - - - - In PostgreSQL versions before 9.4, freezing was - implemented by actually replacing a row's insertion XID - with FrozenTransactionId, which was visible in the - row's xmin system column. Newer versions just set a flag - bit, preserving the row's original xmin for possible - forensic use. However, rows with xmin equal - to FrozenTransactionId (2) may still be found - in databases pg_upgrade'd from pre-9.4 versions. + PostgreSQL's MVCC transaction semantics depend on + being able to compare transaction ID (XID) + numbers: a row version with an insertion XID greater than the + current transaction's XID is in the future and + should not be visible to the current transaction. But since the + on-disk representation of transaction IDs is only 32-bits, the + system is incapable of representing + distances between any two XIDs that exceed + about 2 billion transaction IDs. + - Also, system catalogs may contain rows with xmin equal - to BootstrapTransactionId (1), indicating that they were - inserted during the first phase of initdb. - Like FrozenTransactionId, this special XID is treated as - older than every normal XID. + One of the purposes of periodic vacuuming is to manage the + Transaction Id address space. VACUUM will + mark rows as frozen, indicating that they + were inserted by a transaction that committed sufficiently far in + the past that the effects of the inserting transaction are + certain to be visible to all current and future transactions. + There is, in effect, an infinite distance between a frozen + transaction ID and any unfrozen transaction ID. This allows the + on-disk representation of transaction IDs to recycle the 32-bit + address space efficiently. - - - - controls how old an XID value has to be before rows bearing that XID will be - frozen. Increasing this setting may avoid unnecessary work if the - rows that would otherwise be frozen will soon be modified again, - but decreasing this setting increases - the number of transactions that can elapse before the table must be - vacuumed again. - - - - VACUUM uses the visibility map - to determine which pages of a table must be scanned. Normally, it - will skip pages that don't have any dead row versions even if those pages - might still have row versions with old XID values. Therefore, normal - VACUUMs won't always freeze every old row version in the table. - When that happens, VACUUM will eventually need to perform an - aggressive vacuum, which will freeze all eligible unfrozen - XID and MXID values, including those from all-visible but not all-frozen pages. - In practice most tables require periodic aggressive vacuuming. - - controls when VACUUM does that: all-visible but not all-frozen - pages are scanned if the number of transactions that have passed since the - last such scan is greater than vacuum_freeze_table_age minus - vacuum_freeze_min_age. Setting - vacuum_freeze_table_age to 0 forces VACUUM to - always use its aggressive strategy. - - - - The maximum time that a table can go unvacuumed is two billion - transactions minus the vacuum_freeze_min_age value at - the time of the last aggressive vacuum. If it were to go - unvacuumed for longer than - that, data loss could result. To ensure that this does not happen, - autovacuum is invoked on any table that might contain unfrozen rows with - XIDs older than the age specified by the configuration parameter . (This will happen even if - autovacuum is disabled.) - - - - This implies that if a table is not otherwise vacuumed, - autovacuum will be invoked on it approximately once every - autovacuum_freeze_max_age minus - vacuum_freeze_min_age transactions. - For tables that are regularly vacuumed for space reclamation purposes, - this is of little importance. However, for static tables - (including tables that receive inserts, but no updates or deletes), - there is no need to vacuum for space reclamation, so it can - be useful to try to maximize the interval between forced autovacuums - on very large static tables. Obviously one can do this either by - increasing autovacuum_freeze_max_age or decreasing - vacuum_freeze_min_age. - - - - The effective maximum for vacuum_freeze_table_age is 0.95 * - autovacuum_freeze_max_age; a setting higher than that will be - capped to the maximum. A value higher than - autovacuum_freeze_max_age wouldn't make sense because an - anti-wraparound autovacuum would be triggered at that point anyway, and - the 0.95 multiplier leaves some breathing room to run a manual - VACUUM before that happens. As a rule of thumb, - vacuum_freeze_table_age should be set to a value somewhat - below autovacuum_freeze_max_age, leaving enough gap so that - a regularly scheduled VACUUM or an autovacuum triggered by - normal delete and update activity is run in that window. Setting it too - close could lead to anti-wraparound autovacuums, even though the table - was recently vacuumed to reclaim space, whereas lower values lead to more - frequent aggressive vacuuming. - - - - The sole disadvantage of increasing autovacuum_freeze_max_age - (and vacuum_freeze_table_age along with it) is that - the pg_xact and pg_commit_ts - subdirectories of the database cluster will take more space, because it - must store the commit status and (if track_commit_timestamp is - enabled) timestamp of all transactions back to - the autovacuum_freeze_max_age horizon. The commit status uses - two bits per transaction, so if - autovacuum_freeze_max_age is set to its maximum allowed value - of two billion, pg_xact can be expected to grow to about half - a gigabyte and pg_commit_ts to about 20GB. If this - is trivial compared to your total database size, - setting autovacuum_freeze_max_age to its maximum allowed value - is recommended. Otherwise, set it depending on what you are willing to - allow for pg_xact and pg_commit_ts storage. - (The default, 200 million transactions, translates to about 50MB - of pg_xact storage and about 2GB of pg_commit_ts - storage.) - - - - One disadvantage of decreasing vacuum_freeze_min_age is that - it might cause VACUUM to do useless work: freezing a row - version is a waste of time if the row is modified - soon thereafter (causing it to acquire a new XID). So the setting should - be large enough that rows are not frozen until they are unlikely to change - any more. - - - - To track the age of the oldest unfrozen XIDs in a database, - VACUUM stores XID - statistics in the system tables pg_class and - pg_database. In particular, - the relfrozenxid column of a table's - pg_class row contains the oldest remaining unfrozen - XID at the end of the most recent VACUUM that successfully - advanced relfrozenxid. All rows inserted by - transactions older than this cutoff XID are guaranteed to have been frozen. - Similarly, the datfrozenxid column of a database's - pg_database row is a lower bound on the unfrozen XIDs - appearing in that database — it is just the minimum of the - per-table relfrozenxid values within the database. - A convenient way to - examine this information is to execute queries such as: + + To track the age of the oldest unfrozen XIDs in a database, + VACUUM stores XID statistics in the system + tables pg_class and + pg_database. In particular, the + relfrozenxid column of a table's + pg_class row contains the oldest + remaining unfrozen XID at the end of the most recent + VACUUM. All rows inserted by transactions + older than this cutoff XID are guaranteed to have been frozen. + Similarly, the datfrozenxid column of + a database's pg_database row is a lower + bound on the unfrozen XIDs appearing in that database — it + is just the minimum of the per-table + relfrozenxid values within the + database. A convenient way to examine this information is to + execute queries such as: SELECT c.oid::regclass as table_name, @@ -607,83 +478,13 @@ WHERE c.relkind IN ('r', 'm'); SELECT datname, age(datfrozenxid) FROM pg_database; - The age column measures the number of transactions from the - cutoff XID to the current transaction's XID. - - - - - When the VACUUM command's VERBOSE - parameter is specified, VACUUM prints various - statistics about the table. This includes information about how - relfrozenxid and - relminmxid advanced. The same details appear - in the server log when autovacuum logging (controlled by ) reports on a - VACUUM operation executed by autovacuum. + The age column measures the number of transactions from the + cutoff XID to the current transaction's XID. - - - - VACUUM normally only scans pages that have been modified - since the last vacuum, but relfrozenxid can only be - advanced when every page of the table - that might contain unfrozen XIDs is scanned. This happens when - relfrozenxid is more than - vacuum_freeze_table_age transactions old, when - VACUUM's FREEZE option is used, or when all - pages that are not already all-frozen happen to - require vacuuming to remove dead row versions. When VACUUM - scans every page in the table that is not already all-frozen, it should - set age(relfrozenxid) to a value just a little more than the - vacuum_freeze_min_age setting - that was used (more by the number of transactions started since the - VACUUM started). VACUUM - will set relfrozenxid to the oldest XID - that remains in the table, so it's possible that the final value - will be much more recent than strictly required. - If no relfrozenxid-advancing - VACUUM is issued on the table until - autovacuum_freeze_max_age is reached, an autovacuum will soon - be forced for the table. - - - - If for some reason autovacuum fails to clear old XIDs from a table, the - system will begin to emit warning messages like this when the database's - oldest XIDs reach forty million transactions from the wraparound point: - - -WARNING: database "mydb" must be vacuumed within 39985967 transactions -HINT: To avoid a database shutdown, execute a database-wide VACUUM in that database. - - - (A manual VACUUM should fix the problem, as suggested by the - hint; but note that the VACUUM must be performed by a - superuser, else it will fail to process system catalogs and thus not - be able to advance the database's datfrozenxid.) - If these warnings are - ignored, the system will shut down and refuse to start any new - transactions once there are fewer than three million transactions left - until wraparound: - - -ERROR: database is not accepting commands to avoid wraparound data loss in database "mydb" -HINT: Stop the postmaster and vacuum that database in single-user mode. - - - The three-million-transaction safety margin exists to let the - administrator recover without data loss, by manually executing the - required VACUUM commands. However, since the system will not - execute commands once it has gone into the safety shutdown mode, - the only way to do this is to stop the server and start the server in single-user - mode to execute VACUUM. The shutdown mode is not enforced - in single-user mode. See the reference - page for details about using single-user mode. - + - Multixacts and Wraparound + Managing the 32-bit MultiXactId address space MultiXactId @@ -704,47 +505,109 @@ HINT: Stop the postmaster and vacuum that database in single-user mode. particular multixact ID is stored separately in the pg_multixact subdirectory, and only the multixact ID appears in the xmax field in the tuple header. - Like transaction IDs, multixact IDs are implemented as a - 32-bit counter and corresponding storage, all of which requires - careful aging management, storage cleanup, and wraparound handling. - There is a separate storage area which holds the list of members in - each multixact, which also uses a 32-bit counter and which must also - be managed. + Like transaction IDs, multixact IDs are implemented as a 32-bit + counter and corresponding storage. - Whenever VACUUM scans any part of a table, it will replace - any multixact ID it encounters which is older than - - by a different value, which can be the zero value, a single - transaction ID, or a newer multixact ID. For each table, - pg_class.relminmxid stores the oldest - possible multixact ID still appearing in any tuple of that table. - If this value is older than - , an aggressive - vacuum is forced. As discussed in the previous section, an aggressive - vacuum means that only those pages which are known to be all-frozen will - be skipped. mxid_age() can be used on - pg_class.relminmxid to find its age. + A separate relminmxid field can be + advanced any time relfrozenxid is + advanced. VACUUM manages the MultiXactId + address space by implementing rules that are analogous to the + approach taken with Transaction IDs. Many of the XID-based + settings that influence VACUUM's behavior have + direct MultiXactId analogs. A convenient way to examine + information about the MultiXactId address space is to execute + queries such as: + + +SELECT c.oid::regclass as table_name, + mxid_age(c.relminmxid) +FROM pg_class c +WHERE c.relkind IN ('r', 'm'); + +SELECT datname, mxid_age(datminmxid) FROM pg_database; + + + + + Lazy and eager freezing strategies + + When VACUUM is configured to freeze more + aggressively it will typically set the table's + relfrozenxid and + relminmxid fields to relatively recent + values. However, there can be significant variation among tables + with varying workload characteristics. There can even be + variation in how relfrozenxid + advancement takes place over time for the same table, across + successive VACUUM operations. Sometimes + VACUUM will be able to advance + relfrozenxid and + relminmxid by relatively many + XIDs/MXIDs despite performing relatively little freezing work. On + the other hand VACUUM can sometimes freeze many + individual pages while only advancing + relfrozenxid by as few as one or two + XIDs (this is typically seen following bulk loading). - - Aggressive VACUUMs, regardless of what causes - them, are guaranteed to be able to advance - the table's relminmxid. - Eventually, as all tables in all databases are scanned and their - oldest multixact values are advanced, on-disk storage for older - multixacts can be removed. - + + + When the VACUUM command's VERBOSE + parameter is specified, VACUUM prints various + statistics about the table. This includes information about how + relfrozenxid and + relminmxid advanced, as well as + information about how many pages were newly frozen. The same + details appear in the server log when autovacuum logging + (controlled by ) + reports on a VACUUM operation executed by + autovacuum. + + - As a safety device, an aggressive vacuum scan will - occur for any table whose multixact-age is greater than . Also, if the - storage occupied by multixacts members exceeds 2GB, aggressive vacuum - scans will occur more often for all tables, starting with those that - have the oldest multixact-age. Both of these kinds of aggressive - scans will occur even if autovacuum is nominally disabled. + As a general rule, the design of VACUUM + prioritizes stable and predictable performance characteristics + over time, while still leaving some scope for freezing lazily when + a lazy strategy is likely to avoid unnecessary work altogether. Tables + whose heap relation on-disk size is less than at the start of + VACUUM will have page freezing triggered based + on lazy criteria. Freezing will only take place + when one or more XIDs attain an age greater than , or when one or more MXIDs + attain an age greater than . + + + Tables that are larger than will have + VACUUM trigger freezing for any and all pages + that are eligible to be frozen under the lazy criteria, as well as + pages that VACUUM considers all visible pages. + This is the eager freezing strategy. The design makes the soft + assumption that larger tables will tend to consist of pages that + will only need to be processed by VACUUM once. + The overhead of freezing each page is expected to be slightly + higher in the short term, but much lower in the long term, at + least on average. Eager freezing also limits the accumulation of + unfrozen pages, which tends to improve performance + stability over time. + + + Occasionally, VACUUM is required to advance + relfrozenxid and/or + relminmxid up to a specific value + to ensure the system always has a healthy amount of usable + transaction ID address space. This usually only occurs when + VACUUM must be run by autovacuum specifically + for the purpose of advancing relfrozenxid, + when no VACUUM has been triggered for some + time. In practice most individual tables will consistently have + somewhat recent values through routine vacuuming to clean up old + row versions. @@ -802,117 +665,197 @@ HINT: Stop the postmaster and vacuum that database in single-user mode. limits. - - Tables whose relfrozenxid value is more than - transactions old are always - vacuumed (this also applies to those tables whose freeze max age has - been modified via storage parameters; see below). Otherwise, if the - number of tuples obsoleted since the last - VACUUM exceeds the vacuum threshold, the - table is vacuumed. The vacuum threshold is defined as: + + Triggering thresholds + + Tables whose relfrozenxid value is + more than + transactions old are always vacuumed (this also applies to those + tables whose freeze max age has been modified via storage + parameters; see below). Otherwise, if the number of tuples + obsoleted since the last VACUUM exceeds the + vacuum threshold, the table is vacuumed. The + vacuum threshold is defined as: vacuum threshold = vacuum base threshold + vacuum scale factor * number of tuples - where the vacuum base threshold is - , - the vacuum scale factor is - , + where the vacuum base threshold is , the vacuum scale + factor is , and the number of tuples is pg_class.reltuples. - + - - The table is also vacuumed if the number of tuples inserted since the last - vacuum has exceeded the defined insert threshold, which is defined as: + + The table is also vacuumed if the number of tuples inserted since + the last vacuum has exceeded the defined insert threshold, which + is defined as: vacuum insert threshold = vacuum base insert threshold + vacuum insert scale factor * number of tuples - where the vacuum insert base threshold is - , - and vacuum insert scale factor is - . - Such vacuums may allow portions of the table to be marked as - all visible and also allow tuples to be frozen, which - can reduce the work required in subsequent vacuums. - For tables which receive INSERT operations but no or - almost no UPDATE/DELETE operations, - it may be beneficial to lower the table's - as this may allow - tuples to be frozen by earlier vacuums. The number of obsolete tuples and - the number of inserted tuples are obtained from the cumulative statistics system; - it is a semi-accurate count updated by each UPDATE, - DELETE and INSERT operation. (It is - only semi-accurate because some information might be lost under heavy - load.) If the relfrozenxid value of the table - is more than vacuum_freeze_table_age transactions old, - an aggressive vacuum is performed to freeze old tuples and advance - relfrozenxid; otherwise, only pages that have been modified - since the last vacuum are scanned. - + where the vacuum insert base threshold + is , and + vacuum insert scale factor is . Such + vacuums may allow portions of the table to be marked as + all visible and also allow tuples to be + frozen. The number of obsolete tuples and the number of inserted + tuples are obtained from the cumulative statistics system; it is + a semi-accurate count updated by each UPDATE, + DELETE and INSERT + operation. (It is only semi-accurate because some information + might be lost under heavy load.) + - - For analyze, a similar condition is used: the threshold, defined as: + + For analyze, a similar condition is used: the threshold, defined as: analyze threshold = analyze base threshold + analyze scale factor * number of tuples - is compared to the total number of tuples inserted, updated, or deleted - since the last ANALYZE. - - - - Partitioned tables are not processed by autovacuum. Statistics - should be collected by running a manual ANALYZE when it is - first populated, and again whenever the distribution of data in its - partitions changes significantly. - - - - Temporary tables cannot be accessed by autovacuum. Therefore, - appropriate vacuum and analyze operations should be performed via - session SQL commands. - - - - The default thresholds and scale factors are taken from - postgresql.conf, but it is possible to override them - (and many other autovacuum control parameters) on a per-table basis; see - for more information. - If a setting has been changed via a table's storage parameters, that value - is used when processing that table; otherwise the global settings are - used. See for more details on - the global settings. - - - - When multiple workers are running, the autovacuum cost delay parameters - (see ) are - balanced among all the running workers, so that the - total I/O impact on the system is the same regardless of the number - of workers actually running. However, any workers processing tables whose - per-table autovacuum_vacuum_cost_delay or - autovacuum_vacuum_cost_limit storage parameters have been set - are not considered in the balancing algorithm. - - - - Autovacuum workers generally don't block other commands. If a process - attempts to acquire a lock that conflicts with the - SHARE UPDATE EXCLUSIVE lock held by autovacuum, lock - acquisition will interrupt the autovacuum. For conflicting lock modes, - see . However, if the autovacuum - is running to prevent transaction ID wraparound (i.e., the autovacuum query - name in the pg_stat_activity view ends with - (to prevent wraparound)), the autovacuum is not - automatically interrupted. - - - - - Regularly running commands that acquire locks conflicting with a - SHARE UPDATE EXCLUSIVE lock (e.g., ANALYZE) can - effectively prevent autovacuums from ever completing. + is compared to the total number of tuples inserted, updated, or + deleted since the last ANALYZE. - + + + + + Anti-wraparound autovacuum + + + wraparound + of transaction IDs + + + + wraparound + of multixact IDs + + + + If no relfrozenxid-advancing + VACUUM is issued on the table before + autovacuum_freeze_max_age is reached, an + anti-wraparound autovacuum will soon be launched against the + table. This reliably advances + relfrozenxid when there is no other + reason for VACUUM to run, or when a smaller + table had VACUUM operations that lazily opted + not to advance relfrozenxid. + + + + An anti-wraparound autovacuum will also be triggered for any + table whose multixact-age is greater than . However, + if the storage occupied by multixacts members exceeds 2GB, + anti-wraparound vacuum might occur more often than this. + + + + If for some reason autovacuum fails to clear old XIDs from a table, the + system will begin to emit warning messages like this when the database's + oldest XIDs reach forty million transactions from the wraparound point: + + +WARNING: database "mydb" must be vacuumed within 39985967 transactions +HINT: To avoid a database shutdown, execute a database-wide VACUUM in that database. + + + (A manual VACUUM should fix the problem, as suggested by the + hint; but note that the VACUUM must be performed by a + superuser, else it will fail to process system catalogs and thus not + be able to advance the database's datfrozenxid.) + If these warnings are + ignored, the system will shut down and refuse to start any new + transactions once there are fewer than three million transactions left + until wraparound: + + +ERROR: database is not accepting commands to avoid wraparound data loss in database "mydb" +HINT: Stop the postmaster and vacuum that database in single-user mode. + + + The three-million-transaction safety margin exists to let the + administrator recover by manually executing the required + VACUUM commands. It is usually sufficient to + allow autovacuum to finish against the table with the oldest + relfrozenxid and/or + relminmxid value. The wraparound + failsafe mechanism controlled by and will typically + trigger before warning messages are first emitted. This happens + dynamically, in any antiwraparound autovacuum worker that is + tasked with advancing very old table ages. It will also happen + during manual VACUUM operations. + + + + The shutdown mode is not enforced in single-user mode, which can + be useful in some disaster recovery scenarios. See the reference page for details about using + single-user mode. + + + + + Limitations + + + Partitioned tables are not processed by autovacuum. Statistics + should be collected by running a manual ANALYZE when it is + first populated, and again whenever the distribution of data in its + partitions changes significantly. + + + + Temporary tables cannot be accessed by autovacuum. Therefore, + appropriate vacuum and analyze operations should be performed via + session SQL commands. + + + + The default thresholds and scale factors are taken from + postgresql.conf, but it is possible to override them + (and many other autovacuum control parameters) on a per-table basis; see + for more information. + If a setting has been changed via a table's storage parameters, that value + is used when processing that table; otherwise the global settings are + used. See for more details on + the global settings. + + + + When multiple workers are running, the autovacuum cost delay parameters + (see ) are + balanced among all the running workers, so that the + total I/O impact on the system is the same regardless of the number + of workers actually running. However, any workers processing tables whose + per-table autovacuum_vacuum_cost_delay or + autovacuum_vacuum_cost_limit storage parameters have been set + are not considered in the balancing algorithm. + + + + Autovacuum workers generally don't block other commands. If a process + attempts to acquire a lock that conflicts with the + SHARE UPDATE EXCLUSIVE lock held by autovacuum, lock + acquisition will interrupt the autovacuum. For conflicting lock modes, + see . However, if the autovacuum + is running to prevent transaction ID wraparound (i.e., the autovacuum query + name in the pg_stat_activity view ends with + (to prevent wraparound)), the autovacuum is not + automatically interrupted. + + + + + Regularly running commands that acquire locks conflicting with a + SHARE UPDATE EXCLUSIVE lock (e.g., ANALYZE) can + effectively prevent autovacuums from ever completing. + + + diff --git a/doc/src/sgml/ref/create_table.sgml b/doc/src/sgml/ref/create_table.sgml index eabbf9e65..859175718 100644 --- a/doc/src/sgml/ref/create_table.sgml +++ b/doc/src/sgml/ref/create_table.sgml @@ -1503,7 +1503,7 @@ WITH ( MODULUS numeric_literal, REM and/or ANALYZE operations on this table following the rules discussed in . If false, this table will not be autovacuumed, except to prevent - transaction ID wraparound. See for + transaction ID wraparound. See for more about wraparound prevention. Note that the autovacuum daemon does not run at all (except to prevent transaction ID wraparound) if the diff --git a/doc/src/sgml/ref/prepare_transaction.sgml b/doc/src/sgml/ref/prepare_transaction.sgml index f4f6118ac..1817ed1e3 100644 --- a/doc/src/sgml/ref/prepare_transaction.sgml +++ b/doc/src/sgml/ref/prepare_transaction.sgml @@ -128,7 +128,7 @@ PREPARE TRANSACTION transaction_id This will interfere with the ability of VACUUM to reclaim storage, and in extreme cases could cause the database to shut down to prevent transaction ID wraparound (see ). Keep in mind also that the transaction + linkend="vacuum-xid-space"/>). Keep in mind also that the transaction continues to hold whatever locks it held. The intended usage of the feature is that a prepared transaction will normally be committed or rolled back as soon as an external transaction manager has verified that diff --git a/doc/src/sgml/ref/vacuum.sgml b/doc/src/sgml/ref/vacuum.sgml index c582021d2..43ffbbbd3 100644 --- a/doc/src/sgml/ref/vacuum.sgml +++ b/doc/src/sgml/ref/vacuum.sgml @@ -119,14 +119,14 @@ VACUUM [ FULL ] [ FREEZE ] [ VERBOSE ] [ ANALYZE ] [ and - parameters - set to zero. Aggressive freezing is always performed when the - table is rewritten, so this option is redundant when FULL - is specified. + Selects eager freezing of tuples. Specifying + FREEZE is equivalent to performing + VACUUM with the and parameters set + to zero. Eager freezing is always performed when the table is + rewritten, so this option is redundant when + FULL is specified. @@ -154,13 +154,8 @@ VACUUM [ FULL ] [ FREEZE ] [ VERBOSE ] [ ANALYZE ] [ visibility map. Pages where - all tuples are known to be frozen can always be skipped, and those - where all tuples are known to be visible to all transactions may be - skipped except when performing an aggressive vacuum. Furthermore, - except when performing an aggressive vacuum, some pages may be skipped - in order to avoid waiting for other sessions to finish using them. + Normally, VACUUM will skip pages based on the + visibility map. This option disables all page-skipping behavior, and is intended to be used only when the contents of the visibility map are suspect, which should happen only if there is a hardware or software @@ -215,7 +210,7 @@ VACUUM [ FULL ] [ FREEZE ] [ VERBOSE ] [ ANALYZE ] [ ). However, the + (see ). However, the wraparound failsafe mechanism controlled by will generally trigger automatically to avoid transaction ID wraparound failure, and diff --git a/doc/src/sgml/ref/vacuumdb.sgml b/doc/src/sgml/ref/vacuumdb.sgml index 841aced3b..48942c58f 100644 --- a/doc/src/sgml/ref/vacuumdb.sgml +++ b/doc/src/sgml/ref/vacuumdb.sgml @@ -180,7 +180,7 @@ PostgreSQL documentation - Aggressively freeze tuples. + Eagerly freeze tuples. @@ -259,7 +259,7 @@ PostgreSQL documentation transaction ID age of at least xid_age. This setting is useful for prioritizing tables to process to prevent transaction - ID wraparound (see ). + ID wraparound (see ). For the purposes of this option, the transaction ID age of a relation diff --git a/src/test/isolation/expected/vacuum-no-cleanup-lock.out b/src/test/isolation/expected/vacuum-no-cleanup-lock.out index f7bc93e8f..076fe07ab 100644 --- a/src/test/isolation/expected/vacuum-no-cleanup-lock.out +++ b/src/test/isolation/expected/vacuum-no-cleanup-lock.out @@ -1,6 +1,6 @@ Parsed test spec with 4 sessions -starting permutation: vacuumer_pg_class_stats dml_insert vacuumer_nonaggressive_vacuum vacuumer_pg_class_stats +starting permutation: vacuumer_pg_class_stats dml_insert vacuumer_vacuum_noprune vacuumer_pg_class_stats step vacuumer_pg_class_stats: SELECT relpages, reltuples FROM pg_class WHERE oid = 'smalltbl'::regclass; @@ -12,7 +12,7 @@ relpages|reltuples step dml_insert: INSERT INTO smalltbl SELECT max(id) + 1 FROM smalltbl; -step vacuumer_nonaggressive_vacuum: +step vacuumer_vacuum_noprune: VACUUM smalltbl; step vacuumer_pg_class_stats: @@ -24,7 +24,7 @@ relpages|reltuples (1 row) -starting permutation: vacuumer_pg_class_stats dml_insert pinholder_cursor vacuumer_nonaggressive_vacuum vacuumer_pg_class_stats pinholder_commit +starting permutation: vacuumer_pg_class_stats dml_insert pinholder_cursor vacuumer_vacuum_noprune vacuumer_pg_class_stats pinholder_commit step vacuumer_pg_class_stats: SELECT relpages, reltuples FROM pg_class WHERE oid = 'smalltbl'::regclass; @@ -46,7 +46,7 @@ dummy 1 (1 row) -step vacuumer_nonaggressive_vacuum: +step vacuumer_vacuum_noprune: VACUUM smalltbl; step vacuumer_pg_class_stats: @@ -61,7 +61,7 @@ step pinholder_commit: COMMIT; -starting permutation: vacuumer_pg_class_stats pinholder_cursor dml_insert dml_delete dml_insert vacuumer_nonaggressive_vacuum vacuumer_pg_class_stats pinholder_commit +starting permutation: vacuumer_pg_class_stats pinholder_cursor dml_insert dml_delete dml_insert vacuumer_vacuum_noprune vacuumer_pg_class_stats pinholder_commit step vacuumer_pg_class_stats: SELECT relpages, reltuples FROM pg_class WHERE oid = 'smalltbl'::regclass; @@ -89,7 +89,7 @@ step dml_delete: step dml_insert: INSERT INTO smalltbl SELECT max(id) + 1 FROM smalltbl; -step vacuumer_nonaggressive_vacuum: +step vacuumer_vacuum_noprune: VACUUM smalltbl; step vacuumer_pg_class_stats: @@ -104,7 +104,7 @@ step pinholder_commit: COMMIT; -starting permutation: vacuumer_pg_class_stats dml_insert dml_delete pinholder_cursor dml_insert vacuumer_nonaggressive_vacuum vacuumer_pg_class_stats pinholder_commit +starting permutation: vacuumer_pg_class_stats dml_insert dml_delete pinholder_cursor dml_insert vacuumer_vacuum_noprune vacuumer_pg_class_stats pinholder_commit step vacuumer_pg_class_stats: SELECT relpages, reltuples FROM pg_class WHERE oid = 'smalltbl'::regclass; @@ -132,7 +132,7 @@ dummy step dml_insert: INSERT INTO smalltbl SELECT max(id) + 1 FROM smalltbl; -step vacuumer_nonaggressive_vacuum: +step vacuumer_vacuum_noprune: VACUUM smalltbl; step vacuumer_pg_class_stats: @@ -147,7 +147,7 @@ step pinholder_commit: COMMIT; -starting permutation: dml_begin dml_other_begin dml_key_share dml_other_key_share vacuumer_nonaggressive_vacuum pinholder_cursor dml_other_update dml_commit dml_other_commit vacuumer_nonaggressive_vacuum pinholder_commit vacuumer_nonaggressive_vacuum +starting permutation: dml_begin dml_other_begin dml_key_share dml_other_key_share vacuumer_vacuum_noprune pinholder_cursor dml_other_update dml_commit dml_other_commit vacuumer_vacuum_noprune pinholder_commit vacuumer_vacuum_noprune step dml_begin: BEGIN; step dml_other_begin: BEGIN; step dml_key_share: SELECT id FROM smalltbl WHERE id = 3 FOR KEY SHARE; @@ -162,7 +162,7 @@ id 3 (1 row) -step vacuumer_nonaggressive_vacuum: +step vacuumer_vacuum_noprune: VACUUM smalltbl; step pinholder_cursor: @@ -178,12 +178,12 @@ dummy step dml_other_update: UPDATE smalltbl SET t = 'u' WHERE id = 3; step dml_commit: COMMIT; step dml_other_commit: COMMIT; -step vacuumer_nonaggressive_vacuum: +step vacuumer_vacuum_noprune: VACUUM smalltbl; step pinholder_commit: COMMIT; -step vacuumer_nonaggressive_vacuum: +step vacuumer_vacuum_noprune: VACUUM smalltbl; diff --git a/src/test/isolation/specs/vacuum-no-cleanup-lock.spec b/src/test/isolation/specs/vacuum-no-cleanup-lock.spec index 05fd280f6..998adf526 100644 --- a/src/test/isolation/specs/vacuum-no-cleanup-lock.spec +++ b/src/test/isolation/specs/vacuum-no-cleanup-lock.spec @@ -55,15 +55,18 @@ step dml_other_key_share { SELECT id FROM smalltbl WHERE id = 3 FOR KEY SHARE; step dml_other_update { UPDATE smalltbl SET t = 'u' WHERE id = 3; } step dml_other_commit { COMMIT; } -# This session runs non-aggressive VACUUM, but with maximally aggressive -# cutoffs for tuple freezing (e.g., FreezeLimit == OldestXmin): +# This session runs VACUUM with maximally aggressive cutoffs for tuple +# freezing (e.g., FreezeLimit == OldestXmin), without ever being +# prepared to wait for a cleanup lock (we'll never wait on a cleanup +# lock because autovacuum_freeze_max_age and vacuum_freeze_table_age use +# their default settings). session vacuumer setup { SET vacuum_freeze_min_age = 0; SET vacuum_multixact_freeze_min_age = 0; } -step vacuumer_nonaggressive_vacuum +step vacuumer_vacuum_noprune { VACUUM smalltbl; } @@ -75,15 +78,14 @@ step vacuumer_pg_class_stats # Test VACUUM's reltuples counting mechanism. # # Final pg_class.reltuples should never be affected by VACUUM's inability to -# get a cleanup lock on any page, except to the extent that any cleanup lock -# contention changes the number of tuples that remain ("missed dead" tuples -# are counted in reltuples, much like "recently dead" tuples). +# get a cleanup lock on any page. Note that "missed dead" tuples are counted +# in reltuples, much like "recently dead" tuples. # Easy case: permutation vacuumer_pg_class_stats # Start with 20 tuples dml_insert - vacuumer_nonaggressive_vacuum + vacuumer_vacuum_noprune vacuumer_pg_class_stats # End with 21 tuples # Harder case -- count 21 tuples at the end (like last time), but with cleanup @@ -92,7 +94,7 @@ permutation vacuumer_pg_class_stats # Start with 20 tuples dml_insert pinholder_cursor - vacuumer_nonaggressive_vacuum + vacuumer_vacuum_noprune vacuumer_pg_class_stats # End with 21 tuples pinholder_commit # order doesn't matter @@ -103,7 +105,7 @@ permutation dml_insert dml_delete dml_insert - vacuumer_nonaggressive_vacuum + vacuumer_vacuum_noprune # reltuples is 21 here again -- "recently dead" tuple won't be included in # count here: vacuumer_pg_class_stats @@ -116,7 +118,7 @@ permutation dml_delete pinholder_cursor dml_insert - vacuumer_nonaggressive_vacuum + vacuumer_vacuum_noprune # reltuples is 21 here again -- "missed dead" tuple ("recently dead" when # concurrent activity held back VACUUM's OldestXmin) won't be included in # count here: @@ -128,7 +130,7 @@ permutation # This provides test coverage for code paths that are only hit when we need to # freeze, but inability to acquire a cleanup lock on a heap page makes # freezing some XIDs/MXIDs < FreezeLimit/MultiXactCutoff impossible (without -# waiting for a cleanup lock, which non-aggressive VACUUM is unwilling to do). +# waiting for a cleanup lock, which won't ever happen here). permutation dml_begin dml_other_begin @@ -136,15 +138,15 @@ permutation dml_other_key_share # Will get cleanup lock, can't advance relminmxid yet: # (though will usually advance relfrozenxid by ~2 XIDs) - vacuumer_nonaggressive_vacuum + vacuumer_vacuum_noprune pinholder_cursor dml_other_update dml_commit dml_other_commit # Can't cleanup lock, so still can't advance relminmxid here: # (relfrozenxid held back by XIDs in MultiXact too) - vacuumer_nonaggressive_vacuum + vacuumer_vacuum_noprune pinholder_commit # Pin was dropped, so will advance relminmxid, at long last: # (ditto for relfrozenxid advancement) - vacuumer_nonaggressive_vacuum + vacuumer_vacuum_noprune diff --git a/src/test/regress/expected/reloptions.out b/src/test/regress/expected/reloptions.out index b6aef6f65..9963b165f 100644 --- a/src/test/regress/expected/reloptions.out +++ b/src/test/regress/expected/reloptions.out @@ -102,8 +102,7 @@ SELECT reloptions FROM pg_class WHERE oid = 'reloptions_test'::regclass; INSERT INTO reloptions_test VALUES (1, NULL), (NULL, NULL); ERROR: null value in column "i" of relation "reloptions_test" violates not-null constraint DETAIL: Failing row contains (null, null). --- Do an aggressive vacuum to prevent page-skipping. -VACUUM (FREEZE, DISABLE_PAGE_SKIPPING) reloptions_test; +VACUUM reloptions_test; SELECT pg_relation_size('reloptions_test') > 0; ?column? ---------- @@ -128,8 +127,7 @@ SELECT reloptions FROM pg_class WHERE oid = 'reloptions_test'::regclass; INSERT INTO reloptions_test VALUES (1, NULL), (NULL, NULL); ERROR: null value in column "i" of relation "reloptions_test" violates not-null constraint DETAIL: Failing row contains (null, null). --- Do an aggressive vacuum to prevent page-skipping. -VACUUM (FREEZE, DISABLE_PAGE_SKIPPING) reloptions_test; +VACUUM reloptions_test; SELECT pg_relation_size('reloptions_test') = 0; ?column? ---------- diff --git a/src/test/regress/sql/reloptions.sql b/src/test/regress/sql/reloptions.sql index 4252b0202..5038dbeb3 100644 --- a/src/test/regress/sql/reloptions.sql +++ b/src/test/regress/sql/reloptions.sql @@ -61,8 +61,7 @@ CREATE TEMP TABLE reloptions_test(i INT NOT NULL, j text) autovacuum_enabled=false); SELECT reloptions FROM pg_class WHERE oid = 'reloptions_test'::regclass; INSERT INTO reloptions_test VALUES (1, NULL), (NULL, NULL); --- Do an aggressive vacuum to prevent page-skipping. -VACUUM (FREEZE, DISABLE_PAGE_SKIPPING) reloptions_test; +VACUUM reloptions_test; SELECT pg_relation_size('reloptions_test') > 0; SELECT reloptions FROM pg_class WHERE oid = @@ -72,8 +71,7 @@ SELECT reloptions FROM pg_class WHERE oid = ALTER TABLE reloptions_test RESET (vacuum_truncate); SELECT reloptions FROM pg_class WHERE oid = 'reloptions_test'::regclass; INSERT INTO reloptions_test VALUES (1, NULL), (NULL, NULL); --- Do an aggressive vacuum to prevent page-skipping. -VACUUM (FREEZE, DISABLE_PAGE_SKIPPING) reloptions_test; +VACUUM reloptions_test; SELECT pg_relation_size('reloptions_test') = 0; -- Test toast.* options -- 2.34.1