From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | pgsql-committers(at)lists(dot)postgresql(dot)org |
Subject: | pgsql: Derive freeze cutoff from nextXID, not OldestXmin. |
Date: | 2022-08-31 18:38:51 |
Message-ID: | E1oTSbz-000nHF-7G@gemulon.postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
Derive freeze cutoff from nextXID, not OldestXmin.
Before now, the cutoffs that VACUUM used to determine which XIDs/MXIDs
to freeze were determined at the start of each VACUUM by taking related
cutoffs that represent which XIDs/MXIDs VACUUM should treat as still
running, and subtracting an XID/MXID age based value controlled by GUCs
like vacuum_freeze_min_age. The FreezeLimit cutoff (XID freeze cutoff)
was derived by subtracting an XID age value from OldestXmin, while the
MultiXactCutoff cutoff (MXID freeze cutoff) was derived by subtracting
an MXID age value from OldestMxact. This approach didn't match the
approach used nearby to determine whether this VACUUM operation should
be an aggressive VACUUM or not.
VACUUM now uses the standard approach instead: it subtracts the same
age-based values from next XID/next MXID (rather than subtracting from
OldestXmin/OldestMxact). This approach is simpler and more uniform.
Most of the time it will have only a negligible impact on how and when
VACUUM freezes. It will occasionally make VACUUM more robust in the
event of problems caused by long running transaction. These are cases
where OldestXmin and OldestMxact are held back by so much that they
attain an age that is a significant fraction of the value of age-based
settings like vacuum_freeze_min_age.
There is no principled reason why freezing should be affected in any way
by the presence of a long-running transaction -- at least not before the
point that the OldestXmin and OldestMxact limits used by each VACUUM
operation attain an age that makes it unsafe to freeze some of the
XIDs/MXIDs whose age exceeds the value of the relevant age-based
settings. The new approach should at least make freezing degrade more
gracefully than before, even in the most extreme cases.
Author: Peter Geoghegan <pg(at)bowt(dot)ie>
Reviewed-By: Nathan Bossart <nathandbossart(at)gmail(dot)com>
Reviewed-By: Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>
Discussion: https://postgr.es/m/CAH2-WzkOv5CEeyOO=c91XnT5WBR_0gii0Wn5UbZhJ=4TTykDYg@mail.gmail.com
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/c3ffa731a5f99c4361203015ce2219d209fea94c
Modified Files
--------------
src/backend/access/heap/vacuumlazy.c | 2 +-
src/backend/commands/vacuum.c | 199 ++++++++++++++++-------------------
src/include/commands/vacuum.h | 3 +-
3 files changed, 92 insertions(+), 112 deletions(-)
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2022-08-31 20:23:49 | pgsql: Prevent long-term memory leakage in autovacuum launcher. |
Previous Message | Andres Freund | 2022-08-31 16:42:27 | pgsql: Fix MSVC warning in compat_informix/rnull.pgc |