Bump transaction/multixact ID warning limits to 100M.

These warning limits were last changed to 40M by commit cd5e82256d.
For the benefit of workloads that rapidly consume transactions or
multixacts, this commit bumps the limits to 100M.  This will
hopefully give users enough time to react.

Reviewed-by: Chao Li <li.evan.chao@gmail.com>
Reviewed-by: Shinya Kato <shinya11.kato@gmail.com>
Reviewed-by: wenhui qiu <qiuwenhuifx@gmail.com>
Discussion: https://postgr.es/m/aRdhSSFb9zZH_0zc%40nathan

diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6a9b975084d928c727f977ef2e5e70..75c22405a09f9a8262065b050925ee8974ab12e5 100644 (file)
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
    <para>
     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:
+    oldest XIDs reach one hundred million transactions from the wraparound point:
 
 <programlisting>
-WARNING:  database "mydb" must be vacuumed within 39985967 transactions
-DETAIL:  Approximately 1.86% of transaction IDs are available for use.
+WARNING:  database "mydb" must be vacuumed within 99985967 transactions
+DETAIL:  Approximately 4.66% of transaction IDs are available for use.
 HINT:  To avoid XID assignment failures, execute a database-wide VACUUM in that database.
 </programlisting>
 
@@ -853,7 +853,7 @@ HINT:  Execute a database-wide VACUUM in that database.
 
     <para>
      Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
-     system will begin to emit warning messages when the database's oldest MXIDs reach forty
+     system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
      million transactions from the wraparound point.  And, just as in the XID case, if these
      warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
      than three million left until wraparound.

diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 95d1d265c558991201359e91f25cab7fcc147109..57d2ab4ce3144553055de29a307db608a973b20d 100644 (file)
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2102,16 +2102,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
                multiStopLimit -= FirstMultiXactId;
 
        /*
-        * We'll start complaining loudly when we get within 40M multis of data
+        * We'll start complaining loudly when we get within 100M 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
+        * down to 5% 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 = multiWrapLimit - 40000000;
+       multiWarnLimit = multiWrapLimit - 100000000;
        if (multiWarnLimit < FirstMultiXactId)
                multiWarnLimit -= FirstMultiXactId;
 

diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba2db7d232ea2b96660c7918a0ad2bd..1441a051773f8e49161aefd345b25496c19ba046 100644 (file)
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
                xidStopLimit -= FirstNormalTransactionId;
 
        /*
-        * We'll start complaining loudly when we get within 40M transactions of
+        * We'll start complaining loudly when we get within 100M transactions 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?
+        * get down to 5% 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.)
         */
-       xidWarnLimit = xidWrapLimit - 40000000;
+       xidWarnLimit = xidWrapLimit - 100000000;
        if (xidWarnLimit < FirstNormalTransactionId)
                xidWarnLimit -= FirstNormalTransactionId;