You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Multixact member files are subject to early wraparound overflow and
removal: if the average multixact size is above a certain threshold (see
note below) the protections against offset overflow are not enough:
during multixact truncation at checkpoint time, some
pg_multixact/members files would be removed because the server considers
them to be old and not needed anymore. This leads to loss of files that
are critical to interpret existing tuples's Xmax values.
To protect against this, since we don't have enough info in pg_control
and we can't modify it in old branches, we maintain shared memory state
about the oldest value that we need to keep; we use this during new
multixact creation to abort if an old still-needed file would get
overwritten. This value is kept up to date by checkpoints, which makes
it not completely accurate but should be good enough. We start emitting
warnings sometime earlier, so that the eventual multixact-shutdown
doesn't take DBAs completely by surprise (more precisely: once 20
members SLRU segments are remaining before shutdown.)
On troublesome average multixact size: The threshold size depends on the
multixact freeze parameters. The oldest age is related to the greater of
multixact_freeze_table_age and multixact_freeze_min_age: anything
older than that should be removed promptly by autovacuum. If autovacuum
is keeping up with multixact freezing, the troublesome multixact average
size is
(2^32-1) / Max(freeze table age, freeze min age)
or around 28 members per multixact. Having an average multixact size
larger than that will eventually cause new multixact data to overwrite
the data area for older multixacts. (If autovacuum is not able to keep
up, or there are errors in vacuuming, the actual maximum is
multixact_freeeze_max_age instead, at which point multixact generation
is stopped completely. The default value for this limit is 400 million,
which means that the multixact size that would cause trouble is about 10
members).
Initial bug report by Timothy Garnett, bug #12990
Backpatch to 9.3, where the problem was introduced.
Authors: Álvaro Herrera, Thomas Munro
Reviews: Thomas Munro, Amit Kapila, Robert Haas, Kevin Grittner
* Protect against overrun of the members space as well, with the
1060
+
* following rules:
1061
+
*
1062
+
* If we're past offsetStopLimit, refuse to generate more multis.
1063
+
* If we're close to offsetStopLimit, emit a warning.
1064
+
*
1065
+
* Arbitrarily, we start emitting warnings when we're 20 segments or less
1066
+
* from offsetStopLimit.
1067
+
*
1068
+
* Note we haven't updated the shared state yet, so if we fail at this
1069
+
* point, the multixact ID we grabbed can still be used by the next guy.
1070
+
*
1071
+
* Note that there is no point in forcing autovacuum runs here: the
1072
+
* multixact freeze settings would have to be reduced for that to have any
1073
+
* effect.
1074
+
*----------
1075
+
*/
1076
+
#defineOFFSET_WARN_SEGMENTS 20
1077
+
if (MultiXactOffsetWouldWrap(MultiXactState->offsetStopLimit, nextOffset,
1078
+
nmembers))
1079
+
ereport(ERROR,
1080
+
(errcode(ERRCODE_PROGRAM_LIMIT_EXCEEDED),
1081
+
errmsg("multixact \"members\" limit exceeded"),
1082
+
errdetail_plural("This command would create a multixact with %u members, which exceeds remaining space (%u member.)",
1083
+
"This command would create a multixact with %u members, which exceeds remaining space (%u members.)",
1084
+
MultiXactState->offsetStopLimit-nextOffset-1,
1085
+
nmembers,
1086
+
MultiXactState->offsetStopLimit-nextOffset-1),
1087
+
errhint("Execute a database-wide VACUUM in database with OID %u, with reduced vacuum_multixact_freeze_min_age and vacuum_multixact_freeze_table_age settings.",
errhint("Execute a database-wide VACUUM in that database, with reduced vacuum_multixact_freeze_min_age and vacuum_multixact_freeze_table_age settings.")));
0 commit comments