agora inbox for pgsql-hackers@postgresql.orghelp / color / mirror / Atom feed
[PATCH v1 5/7] Row pattern recognition patch (docs). 681+ messages / 2 participants [nested] [flat]
* [PATCH v1 5/7] Row pattern recognition patch (docs). @ 2023-06-25 11:48 Tatsuo Ishii <ishii@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Tatsuo Ishii @ 2023-06-25 11:48 UTC (permalink / raw) --- doc/src/sgml/advanced.sgml | 51 ++++++++++++++++++++++++++ doc/src/sgml/func.sgml | 69 ++++++++++++++++++++++++++++++++++++ doc/src/sgml/ref/select.sgml | 18 ++++++++-- 3 files changed, 136 insertions(+), 2 deletions(-) diff --git a/doc/src/sgml/advanced.sgml b/doc/src/sgml/advanced.sgml index 755c9f1485..23ee285b40 100644 --- a/doc/src/sgml/advanced.sgml +++ b/doc/src/sgml/advanced.sgml @@ -537,6 +537,57 @@ WHERE pos < 3; <literal>rank</literal> less than 3. </para> + <para> + Window function <function>rpr</function> can be used with row pattern + common syntax to perform row pattern recognition in a query. Row pattern + common syntax includes two sub clauses. <literal>DEFINE</literal> defines + definition variables along with an expression. The expression must be a + logical expression, which means it must + return <literal>TRUE</literal>, <literal>FALSE</literal> + or <literal>NULL</literal>. Moreover if the expression comprises a column + reference, it must be the argument of <function>rpr</function>. An + example of <literal>DEFINE</literal> is as follows. + +<programlisting> +DEFINE + LOWPRICE AS price <= 100, + UP AS price > PREV(price), + DOWN AS price < PREV(price) +</programlisting> + + Note that <function>PREV</function> returns price column in the previous + row if it's called in a context of row pattern recognition. So in the + second line means the definition variable "UP" is <literal>TRUE</literal> + when price column in the current row is greater than the price column in + the previous row. Likewise, "DOWN" is <literal>TRUE</literal> when when + price column in the current row is lower than the price column in the + previous row. + </para> + <para> + Once <literal>DEFINE</literal> exists, <literal>PATTERN</literal> can be + used. <literal>PATTERN</literal> defines a sequence of rows that satisfies + certain conditions. For example following <literal>PATTERN</literal> + defines that a row starts with the condition "LOWPRICE", then one or more + rows satisfy "UP" and finally one or more rows satisfy "DOWN". If a + sequence of rows found, rpr returns the column at the starting row. + Example of a <literal>SELECT</literal> using the <literal>DEFINE</literal> + and <literal>PATTERN</literal> clause is as follows. + +<programlisting> +SELECT company, tdate, price, rpr(price) OVER w FROM stock + WINDOW w AS ( + PARTITION BY company + ROWS BETWEEN CURRENT ROW AND UNBOUNDED FOLLOWING + INITIAL + PATTERN (LOWPRICE UP+ DOWN+) + DEFINE + LOWPRICE AS price <= 100, + UP AS price > PREV(price), + DOWN AS price < PREV(price) +); +</programlisting> + </para> + <para> When a query involves multiple window functions, it is possible to write out each one with a separate <literal>OVER</literal> clause, but this is diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml index 5a47ce4343..8069c58ca5 100644 --- a/doc/src/sgml/func.sgml +++ b/doc/src/sgml/func.sgml @@ -21648,6 +21648,22 @@ SELECT count(*) FROM sometable; returns <literal>NULL</literal> if there is no such row. </para></entry> </row> + + <row> + <entry role="func_table_entry"><para role="func_signature"> + <indexterm> + <primary>rpr</primary> + </indexterm> + <function>rpr</function> ( <parameter>value</parameter> <type>anyelement</type> ) + <returnvalue>anyelement</returnvalue> + </para> + <para> + Perform row pattern recognition using column specified + by <parameter>value</parameter> and returns the value of the column if + current row is the first matching row; + returns <literal>NULL</literal> otherwise. + </para></entry> + </row> </tbody> </tgroup> </table> @@ -21687,6 +21703,59 @@ SELECT count(*) FROM sometable; Other frame specifications can be used to obtain other effects. </para> + <para> + Row pattern recognition navigation functions are listed in + <xref linkend="functions-rpr-navigation-table"/>. These functions + can be used to describe DEFINE clause of Row pattern recognition. + </para> + + <table id="functions-rpr-navigation-table"> + <title>Row Pattern Navigation Functions</title> + <tgroup cols="1"> + <thead> + <row> + <entry role="func_table_entry"><para role="func_signature"> + Function + </para> + <para> + Description + </para></entry> + </row> + </thead> + + <tbody> + <row> + <entry role="func_table_entry"><para role="func_signature"> + <indexterm> + <primary>prev</primary> + </indexterm> + <function>prev</function> ( <parameter>value</parameter> <type>anyelement</type> ) + <returnvalue>anyelement</returnvalue> + </para> + <para> + Returns the column value at the previous row; + returns NULL if there is no previous row in the window frame. + </para></entry> + </row> + + <row> + <entry role="func_table_entry"><para role="func_signature"> + <indexterm> + <primary>next</primary> + </indexterm> + <function>next</function> ( <parameter>value</parameter> <type>anyelement</type> ) + <returnvalue>anyelement</returnvalue> + </para> + <para> + Returns the column value at the next row; + returns NULL if there is no next row in the window frame. + </para></entry> + </row> + + </tbody> + </tgroup> + </table> + <note> <para> The SQL standard defines a <literal>RESPECT NULLS</literal> or diff --git a/doc/src/sgml/ref/select.sgml b/doc/src/sgml/ref/select.sgml index 0ee0cc7e64..c0fc16d773 100644 --- a/doc/src/sgml/ref/select.sgml +++ b/doc/src/sgml/ref/select.sgml @@ -966,8 +966,8 @@ WINDOW <replaceable class="parameter">window_name</replaceable> AS ( <replaceabl The <replaceable class="parameter">frame_clause</replaceable> can be one of <synopsis> -{ RANGE | ROWS | GROUPS } <replaceable>frame_start</replaceable> [ <replaceable>frame_exclusion</replaceable> ] -{ RANGE | ROWS | GROUPS } BETWEEN <replaceable>frame_start</replaceable> AND <replaceable>frame_end</replaceable> [ <replaceable>frame_exclusion</replaceable> ] +{ RANGE | ROWS | GROUPS } <replaceable>frame_start</replaceable> [ <replaceable>frame_exclusion</replaceable> ] [row_pattern_common_syntax] +{ RANGE | ROWS | GROUPS } BETWEEN <replaceable>frame_start</replaceable> AND <replaceable>frame_end</replaceable> [ <replaceable>frame_exclusion</replaceable> ] [row_pattern_common_syntax] </synopsis> where <replaceable>frame_start</replaceable> @@ -1074,6 +1074,20 @@ EXCLUDE NO OTHERS a given peer group will be in the frame or excluded from it. </para> + <para> + The + optional <replaceable class="parameter">row_pattern_common_syntax</replaceable> + defines the <firstterm>row pattern recognition condition</firstterm> for + this + window. <replaceable class="parameter">row_pattern_common_syntax</replaceable> + includes following subclauses. + +<synopsis> +PATTERN <replaceable class="parameter">pattern_variable_name</replaceable>[+] [, ...] +DEFINE <replaceable class="parameter">definition_varible_name</replaceable> AS <replaceable class="parameter">expression</replaceable> [, ...] +</synopsis> + </para> + <para> The purpose of a <literal>WINDOW</literal> clause is to specify the behavior of <firstterm>window functions</firstterm> appearing in the query's -- 2.25.1 ----Next_Part(Sun_Jun_25_21_05_09_2023_126)-- Content-Type: Text/X-Patch; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="v1-0006-Row-pattern-recognition-patch-tests.patch" ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index c8ba94303f1..c23e0a6e260 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 e1ac4bf4c0b..42bce35c887 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2072,16 +2072,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --ChIdkGVrtcKYZbRk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. @ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index b89278ef032..8a12bd5f65a 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 63eb2548da1..67810ea489a 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2327,16 +2327,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 962396bae10..5585381bc8c 100644 --- 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; -- 2.39.5 (Apple Git-154) --i7+bPtDlPvAbCgMY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 8 ++++---- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index f146e14d3d6..75c22405a09 100644 --- 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 9f5f8e692b8..978ade705e7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2092,16 +2092,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 2921148ceba..1441a051773 100644 --- 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; -- 2.50.1 (Apple Git-155) --qmnHGfI3v6dYD6Bi-- ^ permalink raw reply [nested|flat] 681+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. @ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org> 0 siblings, 0 replies; 681+ messages in thread From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw) --- doc/src/sgml/maintenance.sgml | 4 ++-- src/backend/access/transam/multixact.c | 6 +++--- src/backend/access/transam/varsup.c | 6 +++--- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml index 257c6a5435d..3960a23ad71 100644 --- a/doc/src/sgml/maintenance.sgml +++ b/doc/src/sgml/maintenance.sgml @@ -670,7 +670,7 @@ 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 @@ -824,7 +824,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 39e5b691573..27a0baab8c7 100644 --- a/src/backend/access/transam/multixact.c +++ b/src/backend/access/transam/multixact.c @@ -2040,16 +2040,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 32961b9acab..98aeea96e8a 100644 --- 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; -- 2.39.5 (Apple Git-154) --hUJBJnA49L/nki7N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch ^ permalink raw reply [nested|flat] 681+ messages in thread
end of thread, other threads:[~2025-12-12 19:10 UTC | newest] Thread overview: 681+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2023-06-25 11:48 [PATCH v1 5/7] Row pattern recognition patch (docs). Tatsuo Ishii <ishii@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org> 2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox