agora inbox for pgsql-hackers@postgresql.org
help / color / mirror / Atom feedRe: INTERVAL SECOND limited to 59 seconds?
641+ messages / 4 participants
[nested] [flat]
* Re: INTERVAL SECOND limited to 59 seconds?
@ 2009-06-07 18:59 Ron Mayer <rm_pg@cheapcomplexdevices.com>
2009-06-07 19:28 ` Re: INTERVAL SECOND limited to 59 seconds? Tom Lane <tgl@sss.pgh.pa.us>
2009-06-08 07:20 ` Re: INTERVAL SECOND limited to 59 seconds? Sebastien FLAESCH <sf@4js.com>
0 siblings, 2 replies; 641+ messages in thread
From: Ron Mayer @ 2009-06-07 18:59 UTC (permalink / raw)
To: Sebastien FLAESCH <sf@4js.com>; +Cc: pgsql-general@postgresql.org; mmoncure@gmail.com
Finally got around to looking at this thread.
Looks like the original questions from the thread
got resolved, but I found this behaviour surprising:
regression=# select interval '1' day to second;
interval
----------
@ 1 hour
(1 row)
Should this be 1 second?
If so I can send a patch.
regression=# select version();
version
-----------------------------------------------------------------------------------------------------------
PostgreSQL 8.4beta2 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 4.2.4 (Ubuntu 4.2.4-1ubuntu3), 32-bit
(1 row)
^ permalink raw reply [nested|flat] 641+ messages in thread
* Re: INTERVAL SECOND limited to 59 seconds?
2009-06-07 18:59 Re: INTERVAL SECOND limited to 59 seconds? Ron Mayer <rm_pg@cheapcomplexdevices.com>
@ 2009-06-07 19:28 ` Tom Lane <tgl@sss.pgh.pa.us>
2009-06-09 00:25 ` Re: INTERVAL SECOND limited to 59 seconds? Ron Mayer <rm_pg@cheapcomplexdevices.com>
1 sibling, 1 reply; 641+ messages in thread
From: Tom Lane @ 2009-06-07 19:28 UTC (permalink / raw)
To: Ron Mayer <rm_pg@cheapcomplexdevices.com>; +Cc: Sebastien FLAESCH <sf@4js.com>; pgsql-general@postgresql.org; mmoncure@gmail.com
Ron Mayer <rm_pg@cheapcomplexdevices.com> writes:
> Looks like the original questions from the thread
> got resolved, but I found this behaviour surprising:
> regression=# select interval '1' day to second;
> interval
> ----------
> @ 1 hour
> (1 row)
> Should this be 1 second?
That is a bit odd, especially seeing that eg. '1' hour to second
comes out as 1 second. What's making it do that?
regards, tom lane
^ permalink raw reply [nested|flat] 641+ messages in thread
* Re: INTERVAL SECOND limited to 59 seconds?
2009-06-07 18:59 Re: INTERVAL SECOND limited to 59 seconds? Ron Mayer <rm_pg@cheapcomplexdevices.com>
2009-06-07 19:28 ` Re: INTERVAL SECOND limited to 59 seconds? Tom Lane <tgl@sss.pgh.pa.us>
@ 2009-06-09 00:25 ` Ron Mayer <rm_pg@cheapcomplexdevices.com>
2009-06-09 22:41 ` Re: INTERVAL SECOND limited to 59 seconds? Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 641+ messages in thread
From: Ron Mayer @ 2009-06-09 00:25 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Ron Mayer <rm_pg@cheapcomplexdevices.com>; Sebastien FLAESCH <sf@4js.com>; pgsql-general@postgresql.org; mmoncure@gmail.com
Tom Lane wrote:
> Ron Mayer <rm_pg@cheapcomplexdevices.com> writes:
>> Looks like the original questions from the thread
>> got resolved, but I found this behaviour surprising:
>
>> regression=# select interval '1' day to second;
>> interval
>> ----------
>> @ 1 hour
>> (1 row)
>
>> Should this be 1 second?
>
> That is a bit odd, especially seeing that eg. '1' hour to second
> comes out as 1 second. What's making it do that?
What from a design point of view? Seems like it's a side
effect of the logic that makes:
select interval '1 2';
know that the 2 means hours rather than seconds.
Code-wise, it seems because around line 2906 in DecodeInterval:
switch (range) ...
case INTERVAL_MASK(DAY) | INTERVAL_MASK(HOUR) | INTERVAL_MASK(MINUTE) | INTERVAL_MASK(SECOND):
type=DTK_HOUR;
But if I naively change that by making it DTK_SECOND,
I'd break "select interval '1 2' day to second;". I guess I'd need
to tweak it to say: if it follows a days filed it means hours; but
by itself it means seconds?
There's a bit of other odd stuff around there. It seems CVS head accepts
"select interval '1 2' hour;" but not "select interval '1 2' hour to minute;"
regression=# select interval '1 2' hour;
interval
----------------
1 day 02:00:00
(1 row)
and I would have guessed that either both should succeed or both should fail.
And if both succeed I wouldn't have expected 1 day 2 hours......
I'd still be happy to send a patch, but am still trying to figure out
what the desired behavior is. My current impression:
What's the desired behavior for each of these:
select interval '1' day to second;
--- should it be 1 second to be consistent with "select interval 1;"?
--- or an error as Sebastien argued in a different part of the thread?
select interval '1 2' hour;
--- should be an error as "select interval '1 2' hour to minute" is?
--- should be "1 day 2 hours" as cvs head treats
"select interval '1 day 2 hours' hour to minute;"?
--- should be 2 hours?
select interval '1 2' hour to minute;
--- should be an error as "select interval '1 2' hour to minute" is?
--- should be "1 day 2 hours" as cvs head treats
"select interval '1 day 2 hours' hour to minute;"?
--- should be 2 hours?
^ permalink raw reply [nested|flat] 641+ messages in thread
* Re: INTERVAL SECOND limited to 59 seconds?
2009-06-07 18:59 Re: INTERVAL SECOND limited to 59 seconds? Ron Mayer <rm_pg@cheapcomplexdevices.com>
2009-06-07 19:28 ` Re: INTERVAL SECOND limited to 59 seconds? Tom Lane <tgl@sss.pgh.pa.us>
2009-06-09 00:25 ` Re: INTERVAL SECOND limited to 59 seconds? Ron Mayer <rm_pg@cheapcomplexdevices.com>
@ 2009-06-09 22:41 ` Tom Lane <tgl@sss.pgh.pa.us>
2009-06-09 22:59 ` Re: INTERVAL SECOND limited to 59 seconds? Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 641+ messages in thread
From: Tom Lane @ 2009-06-09 22:41 UTC (permalink / raw)
To: Ron Mayer <rm_pg@cheapcomplexdevices.com>; +Cc: Sebastien FLAESCH <sf@4js.com>; pgsql-general@postgresql.org; mmoncure@gmail.com
Ron Mayer <rm_pg@cheapcomplexdevices.com> writes:
> Tom Lane wrote:
>> That is a bit odd, especially seeing that eg. '1' hour to second
>> comes out as 1 second. What's making it do that?
> Code-wise, it seems because around line 2906 in DecodeInterval:
> switch (range) ...
> case INTERVAL_MASK(DAY) | INTERVAL_MASK(HOUR) | INTERVAL_MASK(MINUTE) | INTERVAL_MASK(SECOND):
> type=DTK_HOUR;
> But if I naively change that by making it DTK_SECOND,
> I'd break "select interval '1 2' day to second;". I guess I'd need
> to tweak it to say: if it follows a days filed it means hours; but
> by itself it means seconds?
Well, remember that that code is dealing with an unlabeled rightmost
field. In all the cases except DAY TO MINUTE and DAY TO SECOND, the
choice is to assume that such a field corresponds to the rightmost field
of the declared interval type. So the question is do we want the
current behavior, or do we want to rearrange the switch() so that these
two cases assume MINUTE and SECOND respectively? It's certainly a
trivial code change, but it's not clear what's the right thing.
The cases of interest seem to be outside the spec, so it's not much
help. It says that
22) Let N be the number of <primary datetime field>s in the
precision of the <interval literal>, as specified by <interval
qualifier>.
The <interval literal> being defined shall contain N datetime
components.
and the syntaxes for multi-component literals are mostly not very
ambiguous --- the rightmost component is generally supposed to have
punctuation that disambiguates what it is.
I'm inclined to say that these two cases are out of line with what
the rest of the code does and we should change them. It's a judgement
call, but I can't offhand see a case where the current behavior wouldn't
seem surprising.
Plan C would be to say that these cases are ambiguous and we should
throw error. I'm not too thrilled with that, though, especially since
we didn't throw error in prior versions.
regards, tom lane
^ permalink raw reply [nested|flat] 641+ messages in thread
* Re: INTERVAL SECOND limited to 59 seconds?
2009-06-07 18:59 Re: INTERVAL SECOND limited to 59 seconds? Ron Mayer <rm_pg@cheapcomplexdevices.com>
2009-06-07 19:28 ` Re: INTERVAL SECOND limited to 59 seconds? Tom Lane <tgl@sss.pgh.pa.us>
2009-06-09 00:25 ` Re: INTERVAL SECOND limited to 59 seconds? Ron Mayer <rm_pg@cheapcomplexdevices.com>
2009-06-09 22:41 ` Re: INTERVAL SECOND limited to 59 seconds? Tom Lane <tgl@sss.pgh.pa.us>
@ 2009-06-09 22:59 ` Tom Lane <tgl@sss.pgh.pa.us>
2009-06-10 02:49 ` Re: INTERVAL SECOND limited to 59 seconds? Ron Mayer <rm_pg@cheapcomplexdevices.com>
0 siblings, 1 reply; 641+ messages in thread
From: Tom Lane @ 2009-06-09 22:59 UTC (permalink / raw)
To: Ron Mayer <rm_pg@cheapcomplexdevices.com>; Sebastien FLAESCH <sf@4js.com>; pgsql-general@postgresql.org; mmoncure@gmail.com
I wrote:
> I'm inclined to say that these two cases are out of line with what
> the rest of the code does and we should change them.
Specifically, I'm thinking of a patch like this:
Index: datetime.c
===================================================================
RCS file: /cvsroot/pgsql/src/backend/utils/adt/datetime.c,v
retrieving revision 1.206
diff -c -r1.206 datetime.c
*** datetime.c 1 Jun 2009 16:55:11 -0000 1.206
--- datetime.c 9 Jun 2009 22:47:50 -0000
***************
*** 2917,2933 ****
break;
case INTERVAL_MASK(HOUR):
case INTERVAL_MASK(DAY) | INTERVAL_MASK(HOUR):
- case INTERVAL_MASK(DAY) | INTERVAL_MASK(HOUR) | INTERVAL_MASK(MINUTE):
- case INTERVAL_MASK(DAY) | INTERVAL_MASK(HOUR) | INTERVAL_MASK(MINUTE) | INTERVAL_MASK(SECOND):
type = DTK_HOUR;
break;
case INTERVAL_MASK(MINUTE):
case INTERVAL_MASK(HOUR) | INTERVAL_MASK(MINUTE):
type = DTK_MINUTE;
break;
case INTERVAL_MASK(SECOND):
- case INTERVAL_MASK(HOUR) | INTERVAL_MASK(MINUTE) | INTERVAL_MASK(SECOND):
case INTERVAL_MASK(MINUTE) | INTERVAL_MASK(SECOND):
type = DTK_SECOND;
break;
default:
--- 2917,2933 ----
break;
case INTERVAL_MASK(HOUR):
case INTERVAL_MASK(DAY) | INTERVAL_MASK(HOUR):
type = DTK_HOUR;
break;
case INTERVAL_MASK(MINUTE):
case INTERVAL_MASK(HOUR) | INTERVAL_MASK(MINUTE):
+ case INTERVAL_MASK(DAY) | INTERVAL_MASK(HOUR) | INTERVAL_MASK(MINUTE):
type = DTK_MINUTE;
break;
case INTERVAL_MASK(SECOND):
case INTERVAL_MASK(MINUTE) | INTERVAL_MASK(SECOND):
+ case INTERVAL_MASK(HOUR) | INTERVAL_MASK(MINUTE) | INTERVAL_MASK(SECOND):
+ case INTERVAL_MASK(DAY) | INTERVAL_MASK(HOUR) | INTERVAL_MASK(MINUTE) | INTERVAL_MASK(SECOND):
type = DTK_SECOND;
break;
default:
Experimenting with this, I confirm that it does these things:
regression=# select '100':: interval day to minute;
interval
----------
01:40:00
(1 row)
regression=# select '100':: interval day to second;
interval
----------
00:01:40
(1 row)
which seem a lot less surprising than the current behavior.
It also causes these changes in the regression tests:
*** src/test/regress/expected/interval.out Mon Jun 1 19:29:37 2009
--- src/test/regress/results/interval.out Tue Jun 9 18:49:32 2009
***************
*** 466,476 ****
(1 row)
SELECT interval '1 2' day to minute;
! interval
! ----------------
! 1 day 02:00:00
! (1 row)
!
SELECT interval '1 2:03' day to minute;
interval
----------------
--- 466,474 ----
(1 row)
SELECT interval '1 2' day to minute;
! ERROR: invalid input syntax for type interval: "1 2"
! LINE 1: SELECT interval '1 2' day to minute;
! ^
SELECT interval '1 2:03' day to minute;
interval
----------------
***************
*** 484,494 ****
(1 row)
SELECT interval '1 2' day to second;
! interval
! ----------------
! 1 day 02:00:00
! (1 row)
!
SELECT interval '1 2:03' day to second;
interval
----------------
--- 482,490 ----
(1 row)
SELECT interval '1 2' day to second;
! ERROR: invalid input syntax for type interval: "1 2"
! LINE 1: SELECT interval '1 2' day to second;
! ^
SELECT interval '1 2:03' day to second;
interval
----------------
***************
*** 605,615 ****
(1 row)
SELECT interval '1 2.345' day to second(2);
! interval
! ----------------
! 1 day 02:20:42
! (1 row)
!
SELECT interval '1 2:03' day to second(2);
interval
----------------
--- 601,609 ----
(1 row)
SELECT interval '1 2.345' day to second(2);
! ERROR: invalid input syntax for type interval: "1 2.345"
! LINE 1: SELECT interval '1 2.345' day to second(2);
! ^
SELECT interval '1 2:03' day to second(2);
interval
----------------
Now, all three of these cases throw "invalid input syntax" in 8.3,
so this is not a regression from released behavior. The question
is does anyone think that these syntaxes should be valid? They're
not legal per spec, for sure, and they seem pretty ambiguous to me.
regards, tom lane
^ permalink raw reply [nested|flat] 641+ messages in thread
* Re: INTERVAL SECOND limited to 59 seconds?
2009-06-07 18:59 Re: INTERVAL SECOND limited to 59 seconds? Ron Mayer <rm_pg@cheapcomplexdevices.com>
2009-06-07 19:28 ` Re: INTERVAL SECOND limited to 59 seconds? Tom Lane <tgl@sss.pgh.pa.us>
2009-06-09 00:25 ` Re: INTERVAL SECOND limited to 59 seconds? Ron Mayer <rm_pg@cheapcomplexdevices.com>
2009-06-09 22:41 ` Re: INTERVAL SECOND limited to 59 seconds? Tom Lane <tgl@sss.pgh.pa.us>
2009-06-09 22:59 ` Re: INTERVAL SECOND limited to 59 seconds? Tom Lane <tgl@sss.pgh.pa.us>
@ 2009-06-10 02:49 ` Ron Mayer <rm_pg@cheapcomplexdevices.com>
2009-06-10 02:59 ` Re: INTERVAL SECOND limited to 59 seconds? Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 641+ messages in thread
From: Ron Mayer @ 2009-06-10 02:49 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Ron Mayer <rm_pg@cheapcomplexdevices.com>; Sebastien FLAESCH <sf@4js.com>; pgsql-general@postgresql.org; mmoncure@gmail.com
Tom Lane wrote:
> I wrote:
>> I'm inclined to say that these two cases are out of line with what
>> the rest of the code does and we should change them.
> ...
> Now, all three of these cases throw "invalid input syntax" in 8.3,
> so this is not a regression from released behavior. The question
> is does anyone think that these syntaxes should be valid? They're
> not legal per spec, for sure, and they seem pretty ambiguous to me.
Seems to do a sane thing for all sane inputs I threw at it.
It still accepts one odd input that 8.3 rejected:
regression=# select interval '1 1' hour;
Perhaps the additional patch below fixes that?
***************
*** 3022,3028 **** DecodeInterval(char **field, int *ftype, int nf, int range,
tm->tm_hour += val;
AdjustFractSeconds(fval, tm, fsec, SECS_PER_HOUR);
tmask = DTK_M(HOUR);
! type = DTK_DAY; /* set for next field */
break;
case DTK_DAY:
--- 3022,3029 ----
tm->tm_hour += val;
AdjustFractSeconds(fval, tm, fsec, SECS_PER_HOUR);
tmask = DTK_M(HOUR);
! if (range == (INTERVAL_MASK(DAY) | INTERVAL_MASK(HOUR)))
! type = DTK_DAY; /* set for next field */
break;
case DTK_DAY:
It also gives different answers than 8.3 for "select interval '1 1:' hour"
but I guess that's intended, right?
^ permalink raw reply [nested|flat] 641+ messages in thread
* Re: INTERVAL SECOND limited to 59 seconds?
2009-06-07 18:59 Re: INTERVAL SECOND limited to 59 seconds? Ron Mayer <rm_pg@cheapcomplexdevices.com>
2009-06-07 19:28 ` Re: INTERVAL SECOND limited to 59 seconds? Tom Lane <tgl@sss.pgh.pa.us>
2009-06-09 00:25 ` Re: INTERVAL SECOND limited to 59 seconds? Ron Mayer <rm_pg@cheapcomplexdevices.com>
2009-06-09 22:41 ` Re: INTERVAL SECOND limited to 59 seconds? Tom Lane <tgl@sss.pgh.pa.us>
2009-06-09 22:59 ` Re: INTERVAL SECOND limited to 59 seconds? Tom Lane <tgl@sss.pgh.pa.us>
2009-06-10 02:49 ` Re: INTERVAL SECOND limited to 59 seconds? Ron Mayer <rm_pg@cheapcomplexdevices.com>
@ 2009-06-10 02:59 ` Tom Lane <tgl@sss.pgh.pa.us>
2009-06-10 03:31 ` Re: INTERVAL SECOND limited to 59 seconds? Ron Mayer <rm_pg@cheapcomplexdevices.com>
0 siblings, 1 reply; 641+ messages in thread
From: Tom Lane @ 2009-06-10 02:59 UTC (permalink / raw)
To: Ron Mayer <rm_pg@cheapcomplexdevices.com>; +Cc: Sebastien FLAESCH <sf@4js.com>; pgsql-general@postgresql.org; mmoncure@gmail.com
Ron Mayer <rm_pg@cheapcomplexdevices.com> writes:
> It still accepts one odd input that 8.3 rejected:
> regression=# select interval '1 1' hour;
> Perhaps the additional patch below fixes that?
Hmm, not sure about that one. We decided a week or two back that we
don't want the thing discarding higher-order field values, and this
seems pretty close to that. As the code is set up (plus my patch)
I think it's the case that only the rightmost field specification
of the interval qualifier makes any difference for parsing the value;
the leftmost field doesn't really affect what we think the constant
means. That seems like a nice simple consistency property ...
regards, tom lane
^ permalink raw reply [nested|flat] 641+ messages in thread
* Re: INTERVAL SECOND limited to 59 seconds?
2009-06-07 18:59 Re: INTERVAL SECOND limited to 59 seconds? Ron Mayer <rm_pg@cheapcomplexdevices.com>
2009-06-07 19:28 ` Re: INTERVAL SECOND limited to 59 seconds? Tom Lane <tgl@sss.pgh.pa.us>
2009-06-09 00:25 ` Re: INTERVAL SECOND limited to 59 seconds? Ron Mayer <rm_pg@cheapcomplexdevices.com>
2009-06-09 22:41 ` Re: INTERVAL SECOND limited to 59 seconds? Tom Lane <tgl@sss.pgh.pa.us>
2009-06-09 22:59 ` Re: INTERVAL SECOND limited to 59 seconds? Tom Lane <tgl@sss.pgh.pa.us>
2009-06-10 02:49 ` Re: INTERVAL SECOND limited to 59 seconds? Ron Mayer <rm_pg@cheapcomplexdevices.com>
2009-06-10 02:59 ` Re: INTERVAL SECOND limited to 59 seconds? Tom Lane <tgl@sss.pgh.pa.us>
@ 2009-06-10 03:31 ` Ron Mayer <rm_pg@cheapcomplexdevices.com>
0 siblings, 0 replies; 641+ messages in thread
From: Ron Mayer @ 2009-06-10 03:31 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Ron Mayer <rm_pg@cheapcomplexdevices.com>; Sebastien FLAESCH <sf@4js.com>; pgsql-general@postgresql.org; mmoncure@gmail.com
Tom Lane wrote:
> Ron Mayer <rm_pg@cheapcomplexdevices.com> writes:
>> regression=# select interval '1 1' hour;
>
> Hmm, not sure about that one. We decided a week or two back that we
> don't want the thing discarding higher-order field values, and this
> seems pretty close to that. As the code is set up (plus my patch)
> I think it's the case that only the rightmost field specification
> of the interval qualifier makes any difference for parsing the value;
> the leftmost field doesn't really affect what we think the constant
> means. That seems like a nice simple consistency property ...
Sounds good. I'm happy with it then.
^ permalink raw reply [nested|flat] 641+ messages in thread
* Re: INTERVAL SECOND limited to 59 seconds?
2009-06-07 18:59 Re: INTERVAL SECOND limited to 59 seconds? Ron Mayer <rm_pg@cheapcomplexdevices.com>
@ 2009-06-08 07:20 ` Sebastien FLAESCH <sf@4js.com>
1 sibling, 0 replies; 641+ messages in thread
From: Sebastien FLAESCH @ 2009-06-08 07:20 UTC (permalink / raw)
To: Ron Mayer <rm_pg@cheapcomplexdevices.com>; +Cc: pgsql-general@postgresql.org; mmoncure@gmail.com
This is of course unexpected to me (one day becomes an hour)...
Actually I would even expect an error, because there are missing interval parts.
To represent a valid day to second interval, you should write '1 00:00:00' ...
'1' would be a valid day to day interval.
Always providing all interval units would clarify the user code (avoid complex
rules to get defaults), IMHO.
Just to compare with IFX interval literals:
==============================================================================
> select interval( 1, day to second ) from systables where tabid=1;
201: A syntax error has occurred.
Error in line 1
Near character position 37
> select interval( 1 ) day to second from systables where tabid=1;
1262: Non-numeric character in datetime or interval.
Error in line 1
Near character position 36
> select interval ( 1 11:22:33 ) day to second from systables where tabid=1;
(constant)
1 11:22:33
1 row(s) retrieved.
> select interval ( 1 ) day to day from systables where tabid=1;
(constant)
1
1 row(s) retrieved.
==============================================================================
Seb
Ron Mayer wrote:
> Finally got around to looking at this thread.
> Looks like the original questions from the thread
> got resolved, but I found this behaviour surprising:
>
> regression=# select interval '1' day to second;
> interval
> ----------
> @ 1 hour
> (1 row)
>
> Should this be 1 second?
> If so I can send a patch.
>
>
>
>
>
> regression=# select version();
> version
> -----------------------------------------------------------------------------------------------------------
> PostgreSQL 8.4beta2 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 4.2.4 (Ubuntu 4.2.4-1ubuntu3), 32-bit
> (1 row)
>
^ permalink raw reply [nested|flat] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ 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; 641+ 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] 641+ messages in thread
end of thread, other threads:[~2025-12-12 19:10 UTC | newest]
Thread overview: 641+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2009-06-07 18:59 Re: INTERVAL SECOND limited to 59 seconds? Ron Mayer <rm_pg@cheapcomplexdevices.com>
2009-06-07 19:28 ` Tom Lane <tgl@sss.pgh.pa.us>
2009-06-09 00:25 ` Ron Mayer <rm_pg@cheapcomplexdevices.com>
2009-06-09 22:41 ` Tom Lane <tgl@sss.pgh.pa.us>
2009-06-09 22:59 ` Tom Lane <tgl@sss.pgh.pa.us>
2009-06-10 02:49 ` Ron Mayer <rm_pg@cheapcomplexdevices.com>
2009-06-10 02:59 ` Tom Lane <tgl@sss.pgh.pa.us>
2009-06-10 03:31 ` Ron Mayer <rm_pg@cheapcomplexdevices.com>
2009-06-08 07:20 ` Sebastien FLAESCH <sf@4js.com>
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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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-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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox