database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2026-10-23 13:29:09 +03:00
Code Activity

Avoid division-by-zero when calculating autovacuum MXID score.

Browse Source 
In some cases, effective_multixact_freeze_max_age can be 0, which
presents a division-by-zero hazard for the multixact ID age score
calculation.  To fix, bump it to 1 in that case so that we use the
multixact ID age as the score.  While at it, also document that
this component score scales due to high multixact member space
usage.

Reported-by: Masahiko Sawada <sawada.mshk@gmail.com>
Author: Sami Imseih <samimseih@gmail.com>
Reviewed-by: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Discussion: https://postgr.es/m/CAD21AoC6nKeYAjTvJ9dmBea03GZK9222h_O%3DONmcVuxfyO88Bg%40mail.gmail.com
This commit is contained in:
Nathan Bossart
2026-06-18 10:18:25 -05:00
parent f0a5c4fbfc
commit 1f2297b548
2 changed files with 12 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
doc/src/sgml/maintenance.sgml
View File

@@ -1112,8 +1112,10 @@ analyze threshold = analyze base threshold + analyze scale factor * number of tu
field as compared to
<xref linkend="guc-autovacuum-multixact-freeze-max-age"/>. Furthermore,
this component increases greatly once the age surpasses
<xref linkend="guc-vacuum-multixact-failsafe-age"/>. The final value
for this component can be adjusted via
<xref linkend="guc-vacuum-multixact-failsafe-age"/> or when the number
of multixact member entries created exceeds approximately 2 billion
entries (see <xref linkend="vacuum-for-multixact-wraparound"/>). The
final value for this component can be adjusted via
<xref linkend="guc-autovacuum-multixact-freeze-score-weight"/>. Note
that increasing this parameter's value also lowers the age at which this
component begins scaling aggressively, i.e., the scaling age is divided

11
src/backend/postmaster/autovacuum.c
View File

@@ -3048,7 +3048,10 @@ table_recheck_autovac(Oid relid, HTAB *table_toast_map,
* One exception to the previous paragraph is for tables nearing wraparound,
* i.e., those that have surpassed the effective failsafe ages. In that case,
* the relfrozenxid/relminmxid-based score is scaled aggressively so that the
* table has a decent chance of sorting to the front of the list.
* table has a decent chance of sorting to the front of the list. Furthermore,
* the relminmxid-based score is scaled aggressively as
* effective_multixact_freeze_max_age is lowered due to high multixact member
* space usage.
*
* To adjust how strongly each component contributes to the score, the
* following parameters can be adjusted from their default of 1.0 to anywhere
@@ -3194,13 +3197,15 @@ relation_needs_vacanalyze(Oid relid,
/*
* To calculate the (M)XID age portion of the score, divide the age by its
* respective *_freeze_max_age parameter.
* respective *_freeze_max_age parameter. The multixact_freeze_max_age
* variable might be 0 here (i.e., a division-by-zero hazard), so in that
* case we use the mxid_age as the MXID score.
*/
xid_age = TransactionIdIsNormal(relfrozenxid) ? recentXid - relfrozenxid : 0;
mxid_age = MultiXactIdIsValid(relminmxid) ? recentMulti - relminmxid : 0;
scores->xid = (double) xid_age / freeze_max_age;
scores->mxid = (double) mxid_age / multixact_freeze_max_age;
scores->mxid = (double) mxid_age / Max(1, multixact_freeze_max_age);
/*
* To ensure tables are given increased priority once they begin