database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-11-28 11:44:57 +03:00
Code Activity

Change XID and mxact limits to warn at 40M and stop at 3M.

Browse Source 
We have edge-case bugs when assigning values in the last few dozen pages
before the wrap limit.  We may introduce similar bugs in the future.  At
default BLCKSZ, this makes such bugs unreachable outside of single-user
mode.  Also, when VACUUM began to consume mxacts, multiStopLimit did not
change to compensate.

pg_upgrade may fail on a cluster that was already printing "must be
vacuumed" warnings.  Follow the warning's instructions to clear the
warning, then run pg_upgrade again.  One can still, peacefully consume
98% of XIDs or mxacts, so DBAs need not change routine VACUUM settings.

Discussion: https://postgr.es/m/20200621083513.GA3074645@rfd.leadboat.com
This commit is contained in:
Noah Misch
2020-08-01 15:31:01 -07:00
parent 9f9682783b
commit cd5e82256d
3 changed files with 29 additions and 30 deletions
Download Patch File Download Diff File Expand all files Collapse all files

24
src/backend/access/transam/multixact.c
View File

@@ -2217,28 +2217,24 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiWrapLimit += FirstMultiXactId;
/*
* We'll refuse to continue assigning MultiXactIds once we get within 100
* multi of data loss.
*
* Note: This differs from the magic number used in
* SetTransactionIdLimit() since vacuum itself will never generate new
* multis. XXX actually it does, if it needs to freeze old multis.
* We'll refuse to continue assigning MultiXactIds once we get within 3M
* multi of data loss. See SetTransactionIdLimit.
*/
multiStopLimit = multiWrapLimit - 100;
multiStopLimit = multiWrapLimit - 3000000;
if (multiStopLimit < FirstMultiXactId)
multiStopLimit -= FirstMultiXactId;
/*
* We'll start complaining loudly when we get within 10M multis of the
* stop point. This is kind of arbitrary, but if you let your gas gauge
* get down to 1% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* We'll start complaining loudly when we get within 40M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
* down to 2% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
multiWarnLimit = multiStopLimit - 10000000;
multiWarnLimit = multiWrapLimit - 40000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;