agora inbox for pgsql-hackers@postgresql.org
help / color / mirror / Atom feedProblem with listen_addresses = '*' on 8.4beta2 on AIX
632+ messages / 5 participants
[nested] [flat]
* Problem with listen_addresses = '*' on 8.4beta2 on AIX
@ 2009-06-09 15:57 Albe Laurenz <laurenz.albe@wien.gv.at>
2009-06-09 20:27 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 632+ messages in thread
From: Albe Laurenz @ 2009-06-09 15:57 UTC (permalink / raw)
To: pgsql-hackers; ac@esilo.com
Building 8.4beta2 on my AIX test machine works fine,
but when I set listen_addresses = '*' in postgresql.conf,
the server fails to start.
This is what I get:
LOG: 00000: could not translate service "5432" to address: Hostname and service name not provided or found
LOCATION: StreamServerPort, pqcomm.c:294
WARNING: 01000: could not create listen socket for "*"
LOCATION: PostmasterMain, postmaster.c:843
FATAL: XX000: could not create any TCP/IP sockets
LOCATION: PostmasterMain, postmaster.c:848
It works fine if listen_addresses is the empty string or the hostname,
only with the asterisk it seems to fail.
These are the relevant entries in postgresql.conf:
listen_addresses = '*'
port = 5432
Relevant parts of pg_config:
CONFIGURE = '--prefix=/postgres/8.4' '--with-includes=/usr/local/include' '--with-libraries=/usr/local/lib' '--enable-debug' '--enable-cassert' '--with-ldap' '--without-readline' '--enable-integer-datetimes' '--without-zlib' '--enable-thread-safety' 'CC=gcc -maix64' 'LDFLAGS=-Wl,-bbigtoc'
CC = gcc -maix64
CPPFLAGS = -I/usr/local/include
CFLAGS = -O0 -Wall -Wmissing-prototypes -Wpointer-arith -Wendif-labels -fno-strict-aliasing -g
CFLAGS_SL =
LDFLAGS = -Wl,-bbigtoc -L/usr/local/lib -Wl,-blibpath:/postgres/8.4/lib:/usr/local/lib:/usr/lib:/lib
LDFLAGS_SL = -Wl,-bnoentry -Wl,-H512 -Wl,-bM:SRE
LIBS = -lpgport -lld -lm
VERSION = PostgreSQL 8.4beta2
The operating system is AIX 5.3 ML 03.
This change must have broken the code:
http://archives.postgresql.org/pgsql-committers/2009-01/msg00297.php
If listen_addresses is *, then getaddrinfo() will be called with
NULL for both the first and the second argument, which is not allowed
according to the documentation:
http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.commtechref/doc/c...
and should and does return EAI_NONAME = 8.
I guess that the buildfarm did not fail because it does not use '*'.
Yours,
Laurenz Albe
^ permalink raw reply [nested|flat] 632+ messages in thread
* Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX
2009-06-09 15:57 Problem with listen_addresses = '*' on 8.4beta2 on AIX Albe Laurenz <laurenz.albe@wien.gv.at>
@ 2009-06-09 20:27 ` Tom Lane <tgl@sss.pgh.pa.us>
2009-06-09 21:17 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Andrew Dunstan <andrew@dunslane.net>
0 siblings, 1 reply; 632+ messages in thread
From: Tom Lane @ 2009-06-09 20:27 UTC (permalink / raw)
To: Albe Laurenz <laurenz.albe@wien.gv.at>; +Cc: pgsql-hackers; ac@esilo.com
"Albe Laurenz" <laurenz.albe@wien.gv.at> writes:
> Building 8.4beta2 on my AIX test machine works fine,
> but when I set listen_addresses = '*' in postgresql.conf,
> the server fails to start.
I grow weary of AIX's seemingly-unlimited supply of getaddrinfo
peculiarities. What about forgetting the whole matter and always
using our src/port/ implementation on that OS?
regards, tom lane
^ permalink raw reply [nested|flat] 632+ messages in thread
* Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX
2009-06-09 15:57 Problem with listen_addresses = '*' on 8.4beta2 on AIX Albe Laurenz <laurenz.albe@wien.gv.at>
2009-06-09 20:27 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Tom Lane <tgl@sss.pgh.pa.us>
@ 2009-06-09 21:17 ` Andrew Dunstan <andrew@dunslane.net>
2009-06-09 21:24 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 632+ messages in thread
From: Andrew Dunstan @ 2009-06-09 21:17 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Albe Laurenz <laurenz.albe@wien.gv.at>; pgsql-hackers; ac@esilo.com
Tom Lane wrote:
> "Albe Laurenz" <laurenz.albe@wien.gv.at> writes:
>
>> Building 8.4beta2 on my AIX test machine works fine,
>> but when I set listen_addresses = '*' in postgresql.conf,
>> the server fails to start.
>>
>
> I grow weary of AIX's seemingly-unlimited supply of getaddrinfo
> peculiarities. What about forgetting the whole matter and always
> using our src/port/ implementation on that OS?
>
>
>
I'm assuming that the OP has tested that 8.3 works on the same machine
with listen_addresses = '*'.
If so, then this seems a reasonable suggestion.
cheers
andrew
^ permalink raw reply [nested|flat] 632+ messages in thread
* Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX
2009-06-09 15:57 Problem with listen_addresses = '*' on 8.4beta2 on AIX Albe Laurenz <laurenz.albe@wien.gv.at>
2009-06-09 20:27 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Tom Lane <tgl@sss.pgh.pa.us>
2009-06-09 21:17 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Andrew Dunstan <andrew@dunslane.net>
@ 2009-06-09 21:24 ` Tom Lane <tgl@sss.pgh.pa.us>
2009-06-09 21:38 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Merlin Moncure <mmoncure@gmail.com>
0 siblings, 1 reply; 632+ messages in thread
From: Tom Lane @ 2009-06-09 21:24 UTC (permalink / raw)
To: Andrew Dunstan <andrew@dunslane.net>; +Cc: Albe Laurenz <laurenz.albe@wien.gv.at>; pgsql-hackers; ac@esilo.com
Andrew Dunstan <andrew@dunslane.net> writes:
> Tom Lane wrote:
>> I grow weary of AIX's seemingly-unlimited supply of getaddrinfo
>> peculiarities. What about forgetting the whole matter and always
>> using our src/port/ implementation on that OS?
> I'm assuming that the OP has tested that 8.3 works on the same machine
> with listen_addresses = '*'.
> If so, then this seems a reasonable suggestion.
The only serious knock I can see on our implementation is that it lacks
IPv6 support. So we'd not want to use it on AIX versions that are
IPv6-capable. Which are those, if any, and do they have any of these
getaddrinfo issues?
regards, tom lane
^ permalink raw reply [nested|flat] 632+ messages in thread
* Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX
2009-06-09 15:57 Problem with listen_addresses = '*' on 8.4beta2 on AIX Albe Laurenz <laurenz.albe@wien.gv.at>
2009-06-09 20:27 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Tom Lane <tgl@sss.pgh.pa.us>
2009-06-09 21:17 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Andrew Dunstan <andrew@dunslane.net>
2009-06-09 21:24 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Tom Lane <tgl@sss.pgh.pa.us>
@ 2009-06-09 21:38 ` Merlin Moncure <mmoncure@gmail.com>
2009-06-09 22:11 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 632+ messages in thread
From: Merlin Moncure @ 2009-06-09 21:38 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Andrew Dunstan <andrew@dunslane.net>; Albe Laurenz <laurenz.albe@wien.gv.at>; pgsql-hackers; ac@esilo.com
On Tue, Jun 9, 2009 at 5:24 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
>> Tom Lane wrote:
>>> I grow weary of AIX's seemingly-unlimited supply of getaddrinfo
>>> peculiarities. Â What about forgetting the whole matter and always
>>> using our src/port/ implementation on that OS?
>
>> I'm assuming that the OP has tested that 8.3 works on the same machine
>> with listen_addresses = '*'.
>> If so, then this seems a reasonable suggestion.
>
> The only serious knock I can see on our implementation is that it lacks
> IPv6 support. Â So we'd not want to use it on AIX versions that are
> IPv6-capable. Â Which are those, if any, and do they have any of these
> getaddrinfo issues?
actually, aix was the first commercial unix distribution to support
ipv6 afaik...as of 4.3 iirc.
merlin
^ permalink raw reply [nested|flat] 632+ messages in thread
* Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX
2009-06-09 15:57 Problem with listen_addresses = '*' on 8.4beta2 on AIX Albe Laurenz <laurenz.albe@wien.gv.at>
2009-06-09 20:27 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Tom Lane <tgl@sss.pgh.pa.us>
2009-06-09 21:17 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Andrew Dunstan <andrew@dunslane.net>
2009-06-09 21:24 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Tom Lane <tgl@sss.pgh.pa.us>
2009-06-09 21:38 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Merlin Moncure <mmoncure@gmail.com>
@ 2009-06-09 22:11 ` Tom Lane <tgl@sss.pgh.pa.us>
2009-06-10 07:38 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Albe Laurenz <laurenz.albe@wien.gv.at>
0 siblings, 1 reply; 632+ messages in thread
From: Tom Lane @ 2009-06-09 22:11 UTC (permalink / raw)
To: Merlin Moncure <mmoncure@gmail.com>; +Cc: Andrew Dunstan <andrew@dunslane.net>; Albe Laurenz <laurenz.albe@wien.gv.at>; pgsql-hackers; ac@esilo.com
Merlin Moncure <mmoncure@gmail.com> writes:
> Tom Lane wrote:
>> The only serious knock I can see on our implementation is that it lacks
>> IPv6 support. So we'd not want to use it on AIX versions that are
>> IPv6-capable. Which are those, if any, and do they have any of these
>> getaddrinfo issues?
> actually, aix was the first commercial unix distribution to support
> ipv6 afaik...as of 4.3 iirc.
Drat. Okay, that easy solution probably won't fly. Anyone with AIX
access want to try to develop a patch that covers this case without
breaking the other ones?
regards, tom lane
^ permalink raw reply [nested|flat] 632+ messages in thread
* Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX
2009-06-09 15:57 Problem with listen_addresses = '*' on 8.4beta2 on AIX Albe Laurenz <laurenz.albe@wien.gv.at>
2009-06-09 20:27 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Tom Lane <tgl@sss.pgh.pa.us>
2009-06-09 21:17 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Andrew Dunstan <andrew@dunslane.net>
2009-06-09 21:24 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Tom Lane <tgl@sss.pgh.pa.us>
2009-06-09 21:38 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Merlin Moncure <mmoncure@gmail.com>
2009-06-09 22:11 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Tom Lane <tgl@sss.pgh.pa.us>
@ 2009-06-10 07:38 ` Albe Laurenz <laurenz.albe@wien.gv.at>
2009-06-10 13:15 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Merlin Moncure <mmoncure@gmail.com>
0 siblings, 1 reply; 632+ messages in thread
From: Albe Laurenz @ 2009-06-10 07:38 UTC (permalink / raw)
To: Tom Lane *EXTERN* <tgl@sss.pgh.pa.us>; Merlin Moncure <mmoncure@gmail.com>; +Cc: Andrew Dunstan <andrew@dunslane.net>; pgsql-hackers; ac@esilo.com
Tom Lane wrote:
> Drat. Okay, that easy solution probably won't fly. Anyone with AIX
> access want to try to develop a patch that covers this case without
> breaking the other ones?
I can try, but I only have AIX 5.3 to test with, so I won't be able
to test for bugs in other versions.
I would need to know what the problems with getaddrinfo on AIX are.
Is this an exhaustive list?
http://archives.postgresql.org/pgsql-hackers/2009-01/msg01705.php
http://archives.postgresql.org/pgsql-hackers/2006-10/msg01069.php
http://archives.postgresql.org/pgsql-general/2006-10/msg00909.php
http://archives.postgresql.org/pgsql-hackers/2004-07/msg01018.php
http://archives.postgresql.org/pgsql-hackers/2004-04/msg00474.php
I'll also try to investigate known bugs in AIX' getaddrinfo.
AIX 4.3 has been out of support for some time - if it makes the
task easier, would it be an option to desupport it?
Yours,
Laurenz Albe
^ permalink raw reply [nested|flat] 632+ messages in thread
* Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX
2009-06-09 15:57 Problem with listen_addresses = '*' on 8.4beta2 on AIX Albe Laurenz <laurenz.albe@wien.gv.at>
2009-06-09 20:27 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Tom Lane <tgl@sss.pgh.pa.us>
2009-06-09 21:17 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Andrew Dunstan <andrew@dunslane.net>
2009-06-09 21:24 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Tom Lane <tgl@sss.pgh.pa.us>
2009-06-09 21:38 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Merlin Moncure <mmoncure@gmail.com>
2009-06-09 22:11 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Tom Lane <tgl@sss.pgh.pa.us>
2009-06-10 07:38 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Albe Laurenz <laurenz.albe@wien.gv.at>
@ 2009-06-10 13:15 ` Merlin Moncure <mmoncure@gmail.com>
2009-06-10 15:38 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Albe Laurenz <laurenz.albe@wien.gv.at>
0 siblings, 1 reply; 632+ messages in thread
From: Merlin Moncure @ 2009-06-10 13:15 UTC (permalink / raw)
To: Albe Laurenz <laurenz.albe@wien.gv.at>; +Cc: Tom Lane *EXTERN* <tgl@sss.pgh.pa.us>; Andrew Dunstan <andrew@dunslane.net>; pgsql-hackers; ac@esilo.com
On Wed, Jun 10, 2009 at 3:38 AM, Albe Laurenz<laurenz.albe@wien.gv.at> wrote:
> Tom Lane wrote:
>> Drat. Â Okay, that easy solution probably won't fly. Â Anyone with AIX
>> access want to try to develop a patch that covers this case without
>> breaking the other ones?
>
> I can try, but I only have AIX 5.3 to test with, so I won't be able
> to test for bugs in other versions.
>
> I would need to know what the problems with getaddrinfo on AIX are.
> Is this an exhaustive list?
> http://archives.postgresql.org/pgsql-hackers/2009-01/msg01705.php
> http://archives.postgresql.org/pgsql-hackers/2006-10/msg01069.php
> http://archives.postgresql.org/pgsql-general/2006-10/msg00909.php
> http://archives.postgresql.org/pgsql-hackers/2004-07/msg01018.php
> http://archives.postgresql.org/pgsql-hackers/2004-04/msg00474.php
>
> I'll also try to investigate known bugs in AIX' getaddrinfo.
>
> AIX 4.3 has been out of support for some time - if it makes the
> task easier, would it be an option to desupport it?
We have 4.3 and a 6.0 here. 4.3 is pretty old, I don't think it's a
big deal if we can't get it to work, as long as libpq works.
merlin
^ permalink raw reply [nested|flat] 632+ messages in thread
* Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX
2009-06-09 15:57 Problem with listen_addresses = '*' on 8.4beta2 on AIX Albe Laurenz <laurenz.albe@wien.gv.at>
2009-06-09 20:27 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Tom Lane <tgl@sss.pgh.pa.us>
2009-06-09 21:17 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Andrew Dunstan <andrew@dunslane.net>
2009-06-09 21:24 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Tom Lane <tgl@sss.pgh.pa.us>
2009-06-09 21:38 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Merlin Moncure <mmoncure@gmail.com>
2009-06-09 22:11 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Tom Lane <tgl@sss.pgh.pa.us>
2009-06-10 07:38 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Albe Laurenz <laurenz.albe@wien.gv.at>
2009-06-10 13:15 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Merlin Moncure <mmoncure@gmail.com>
@ 2009-06-10 15:38 ` Albe Laurenz <laurenz.albe@wien.gv.at>
2009-06-10 16:13 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 632+ messages in thread
From: Albe Laurenz @ 2009-06-10 15:38 UTC (permalink / raw)
To: Merlin Moncure *EXTERN* <mmoncure@gmail.com>; +Cc: Tom Lane *EXTERN* <tgl@sss.pgh.pa.us>; Andrew Dunstan <andrew@dunslane.net>; pgsql-hackers; ac@esilo.com
Merlin Moncure wrote:
> I wrote:
>> I can try, but I only have AIX 5.3 to test with, so I won't be able
>> to test for bugs in other versions.
>>
>> I would need to know what the problems with getaddrinfo on AIX are.
>>
>> I'll also try to investigate known bugs in AIX' getaddrinfo.
>>
>> AIX 4.3 has been out of support for some time - if it makes the
>> task easier, would it be an option to desupport it?
>
> We have 4.3 and a 6.0 here. 4.3 is pretty old, I don't think it's a
> big deal if we can't get it to work, as long as libpq works.
Ok, I did a bit of research here.
First, the only cases that affect us are the following:
a) listen_addresses = '*'
Then the "hostname" argument to getaddrinfo will be NULL, and
the "servname" argument will be "5432" or similar.
b) listen_addresses = ''
This does not affect us, since it will not call getaddrinfo.
c) listen_addresses = 'host1[,...]'
Then the "hostname" argument will be host1 (DNS name or IPv4/6
address), and "servname" will be "5432" or similar.
Moreover, in the struct addrinfo "hint", the following will be set:
ai_flags = AI_PASSIVE
ai_family = AF_UNSPEC
ai_socktype = SOCK_STREAM
and all other hints will be zero.
Did I cover all cases?
I tested getaddrinfo() on my AIX 5.3 ML 03 with these cases,
and I did not encounter any problems and the result looked right.
I searched the bug database at IBM, and the only APARs that looked
like they might affect us are:
IY40908, IY45130 = IY44782, IY47326 = IY46612 = IY48232, IY46023,
IY51966 = IY50970, IY54776, IZ00799 and IY86414 = IY86549.
Since it works on my system, I wonder if the machines where it fails did
not have any fixpacks installed.
Does Andrew Chernow's machine have the terminal fixpack installed?
I wonder what problem he encountered when he said "the service argument
to getaddrinfo is busted on AIX 4.3".
Maybe it would be good enough to state that AIX is only supported with
certain fixpacks installed? And do without all the AIX hacks?
Yours,
Laurenz Albe
^ permalink raw reply [nested|flat] 632+ messages in thread
* Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX
2009-06-09 15:57 Problem with listen_addresses = '*' on 8.4beta2 on AIX Albe Laurenz <laurenz.albe@wien.gv.at>
2009-06-09 20:27 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Tom Lane <tgl@sss.pgh.pa.us>
2009-06-09 21:17 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Andrew Dunstan <andrew@dunslane.net>
2009-06-09 21:24 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Tom Lane <tgl@sss.pgh.pa.us>
2009-06-09 21:38 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Merlin Moncure <mmoncure@gmail.com>
2009-06-09 22:11 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Tom Lane <tgl@sss.pgh.pa.us>
2009-06-10 07:38 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Albe Laurenz <laurenz.albe@wien.gv.at>
2009-06-10 13:15 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Merlin Moncure <mmoncure@gmail.com>
2009-06-10 15:38 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Albe Laurenz <laurenz.albe@wien.gv.at>
@ 2009-06-10 16:13 ` Tom Lane <tgl@sss.pgh.pa.us>
2009-06-10 18:15 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Merlin Moncure <mmoncure@gmail.com>
0 siblings, 1 reply; 632+ messages in thread
From: Tom Lane @ 2009-06-10 16:13 UTC (permalink / raw)
To: Albe Laurenz <laurenz.albe@wien.gv.at>; +Cc: Merlin Moncure *EXTERN* <mmoncure@gmail.com>; Andrew Dunstan <andrew@dunslane.net>; pgsql-hackers; ac@esilo.com
"Albe Laurenz" <laurenz.albe@wien.gv.at> writes:
> Maybe it would be good enough to state that AIX is only supported with
> certain fixpacks installed? And do without all the AIX hacks?
That would definitely be a good-enough solution in my opinion,
as long as we can document which fixes are needed for which releases.
regards, tom lane
^ permalink raw reply [nested|flat] 632+ messages in thread
* Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX
2009-06-09 15:57 Problem with listen_addresses = '*' on 8.4beta2 on AIX Albe Laurenz <laurenz.albe@wien.gv.at>
2009-06-09 20:27 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Tom Lane <tgl@sss.pgh.pa.us>
2009-06-09 21:17 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Andrew Dunstan <andrew@dunslane.net>
2009-06-09 21:24 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Tom Lane <tgl@sss.pgh.pa.us>
2009-06-09 21:38 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Merlin Moncure <mmoncure@gmail.com>
2009-06-09 22:11 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Tom Lane <tgl@sss.pgh.pa.us>
2009-06-10 07:38 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Albe Laurenz <laurenz.albe@wien.gv.at>
2009-06-10 13:15 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Merlin Moncure <mmoncure@gmail.com>
2009-06-10 15:38 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Albe Laurenz <laurenz.albe@wien.gv.at>
2009-06-10 16:13 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Tom Lane <tgl@sss.pgh.pa.us>
@ 2009-06-10 18:15 ` Merlin Moncure <mmoncure@gmail.com>
2009-06-10 18:19 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Andrew Dunstan <andrew@dunslane.net>
2009-06-11 13:50 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 2 replies; 632+ messages in thread
From: Merlin Moncure @ 2009-06-10 18:15 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Albe Laurenz <laurenz.albe@wien.gv.at>; Andrew Dunstan <andrew@dunslane.net>; pgsql-hackers; ac@esilo.com
On Wed, Jun 10, 2009 at 12:13 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
> "Albe Laurenz" <laurenz.albe@wien.gv.at> writes:
>> Maybe it would be good enough to state that AIX is only supported with
>> certain fixpacks installed? And do without all the AIX hacks?
>
> That would definitely be a good-enough solution in my opinion,
> as long as we can document which fixes are needed for which releases.
my take is to go with Albe's solution. I'm downloading the cumulative
fixpack for 4.3.3:
http://www14.software.ibm.com/webapp/set2/sas/f/aix433fixes/ml11package.html
If the above fixes the problem with the aix hacks removed, problem
solved. If it doesn't, then let's face the music and formally drop
support for aix 4.3 for 8.4. (and, other than that, do nothing).
merlin
^ permalink raw reply [nested|flat] 632+ messages in thread
* Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX
2009-06-09 15:57 Problem with listen_addresses = '*' on 8.4beta2 on AIX Albe Laurenz <laurenz.albe@wien.gv.at>
2009-06-09 20:27 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Tom Lane <tgl@sss.pgh.pa.us>
2009-06-09 21:17 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Andrew Dunstan <andrew@dunslane.net>
2009-06-09 21:24 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Tom Lane <tgl@sss.pgh.pa.us>
2009-06-09 21:38 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Merlin Moncure <mmoncure@gmail.com>
2009-06-09 22:11 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Tom Lane <tgl@sss.pgh.pa.us>
2009-06-10 07:38 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Albe Laurenz <laurenz.albe@wien.gv.at>
2009-06-10 13:15 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Merlin Moncure <mmoncure@gmail.com>
2009-06-10 15:38 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Albe Laurenz <laurenz.albe@wien.gv.at>
2009-06-10 16:13 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Tom Lane <tgl@sss.pgh.pa.us>
2009-06-10 18:15 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Merlin Moncure <mmoncure@gmail.com>
@ 2009-06-10 18:19 ` Andrew Dunstan <andrew@dunslane.net>
1 sibling, 0 replies; 632+ messages in thread
From: Andrew Dunstan @ 2009-06-10 18:19 UTC (permalink / raw)
To: Merlin Moncure <mmoncure@gmail.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Albe Laurenz <laurenz.albe@wien.gv.at>; pgsql-hackers; ac@esilo.com
Merlin Moncure wrote:
> On Wed, Jun 10, 2009 at 12:13 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
>
>> "Albe Laurenz" <laurenz.albe@wien.gv.at> writes:
>>
>>> Maybe it would be good enough to state that AIX is only supported with
>>> certain fixpacks installed? And do without all the AIX hacks?
>>>
>> That would definitely be a good-enough solution in my opinion,
>> as long as we can document which fixes are needed for which releases.
>>
>
> my take is to go with Albe's solution. I'm downloading the cumulative
> fixpack for 4.3.3:
>
> http://www14.software.ibm.com/webapp/set2/sas/f/aix433fixes/ml11package.html
>
> If the above fixes the problem with the aix hacks removed, problem
> solved. If it doesn't, then let's face the music and formally drop
> support for aix 4.3 for 8.4. (and, other than that, do nothing).
>
You mean nothing other than removing the AIX hacks?
(I'm with Tom. This has been a constant annoyance over quite a few years.)
cheers
andrew
^ permalink raw reply [nested|flat] 632+ messages in thread
* Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX
2009-06-09 15:57 Problem with listen_addresses = '*' on 8.4beta2 on AIX Albe Laurenz <laurenz.albe@wien.gv.at>
2009-06-09 20:27 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Tom Lane <tgl@sss.pgh.pa.us>
2009-06-09 21:17 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Andrew Dunstan <andrew@dunslane.net>
2009-06-09 21:24 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Tom Lane <tgl@sss.pgh.pa.us>
2009-06-09 21:38 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Merlin Moncure <mmoncure@gmail.com>
2009-06-09 22:11 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Tom Lane <tgl@sss.pgh.pa.us>
2009-06-10 07:38 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Albe Laurenz <laurenz.albe@wien.gv.at>
2009-06-10 13:15 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Merlin Moncure <mmoncure@gmail.com>
2009-06-10 15:38 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Albe Laurenz <laurenz.albe@wien.gv.at>
2009-06-10 16:13 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Tom Lane <tgl@sss.pgh.pa.us>
2009-06-10 18:15 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Merlin Moncure <mmoncure@gmail.com>
@ 2009-06-11 13:50 ` Tom Lane <tgl@sss.pgh.pa.us>
2009-06-11 14:13 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Merlin Moncure <mmoncure@gmail.com>
1 sibling, 1 reply; 632+ messages in thread
From: Tom Lane @ 2009-06-11 13:50 UTC (permalink / raw)
To: Merlin Moncure <mmoncure@gmail.com>; +Cc: Albe Laurenz <laurenz.albe@wien.gv.at>; Andrew Dunstan <andrew@dunslane.net>; pgsql-hackers; ac@esilo.com
Merlin Moncure <mmoncure@gmail.com> writes:
>> "Albe Laurenz" <laurenz.albe@wien.gv.at> writes:
>>> Maybe it would be good enough to state that AIX is only supported with
>>> certain fixpacks installed? And do without all the AIX hacks?
> my take is to go with Albe's solution. I'm downloading the cumulative
> fixpack for 4.3.3:
> http://www14.software.ibm.com/webapp/set2/sas/f/aix433fixes/ml11package.html
> If the above fixes the problem with the aix hacks removed, problem
> solved. If it doesn't, then let's face the music and formally drop
> support for aix 4.3 for 8.4. (and, other than that, do nothing).
Where are we on this?
regards, tom lane
^ permalink raw reply [nested|flat] 632+ messages in thread
* Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX
2009-06-09 15:57 Problem with listen_addresses = '*' on 8.4beta2 on AIX Albe Laurenz <laurenz.albe@wien.gv.at>
2009-06-09 20:27 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Tom Lane <tgl@sss.pgh.pa.us>
2009-06-09 21:17 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Andrew Dunstan <andrew@dunslane.net>
2009-06-09 21:24 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Tom Lane <tgl@sss.pgh.pa.us>
2009-06-09 21:38 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Merlin Moncure <mmoncure@gmail.com>
2009-06-09 22:11 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Tom Lane <tgl@sss.pgh.pa.us>
2009-06-10 07:38 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Albe Laurenz <laurenz.albe@wien.gv.at>
2009-06-10 13:15 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Merlin Moncure <mmoncure@gmail.com>
2009-06-10 15:38 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Albe Laurenz <laurenz.albe@wien.gv.at>
2009-06-10 16:13 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Tom Lane <tgl@sss.pgh.pa.us>
2009-06-10 18:15 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Merlin Moncure <mmoncure@gmail.com>
2009-06-11 13:50 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Tom Lane <tgl@sss.pgh.pa.us>
@ 2009-06-11 14:13 ` Merlin Moncure <mmoncure@gmail.com>
2009-06-11 14:26 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 632+ messages in thread
From: Merlin Moncure @ 2009-06-11 14:13 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Albe Laurenz <laurenz.albe@wien.gv.at>; Andrew Dunstan <andrew@dunslane.net>; pgsql-hackers; ac@esilo.com
On Thu, Jun 11, 2009 at 9:50 AM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
> Merlin Moncure <mmoncure@gmail.com> writes:
>>> "Albe Laurenz" <laurenz.albe@wien.gv.at> writes:
>>>> Maybe it would be good enough to state that AIX is only supported with
>>>> certain fixpacks installed? And do without all the AIX hacks?
>
>> my take is to go with Albe's solution. Â I'm downloading the cumulative
>> fixpack for 4.3.3:
>
>> http://www14.software.ibm.com/webapp/set2/sas/f/aix433fixes/ml11package.html
>
>> If the above fixes the problem with the aix hacks removed, problem
>> solved. Â If it doesn't, then let's face the music and formally drop
>> support for aix 4.3 for 8.4. Â (and, other than that, do nothing).
>
> Where are we on this?
waiting on a patch? Albe? (or should I do it myself?)
merlin
^ permalink raw reply [nested|flat] 632+ messages in thread
* Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX
2009-06-09 15:57 Problem with listen_addresses = '*' on 8.4beta2 on AIX Albe Laurenz <laurenz.albe@wien.gv.at>
2009-06-09 20:27 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Tom Lane <tgl@sss.pgh.pa.us>
2009-06-09 21:17 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Andrew Dunstan <andrew@dunslane.net>
2009-06-09 21:24 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Tom Lane <tgl@sss.pgh.pa.us>
2009-06-09 21:38 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Merlin Moncure <mmoncure@gmail.com>
2009-06-09 22:11 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Tom Lane <tgl@sss.pgh.pa.us>
2009-06-10 07:38 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Albe Laurenz <laurenz.albe@wien.gv.at>
2009-06-10 13:15 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Merlin Moncure <mmoncure@gmail.com>
2009-06-10 15:38 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Albe Laurenz <laurenz.albe@wien.gv.at>
2009-06-10 16:13 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Tom Lane <tgl@sss.pgh.pa.us>
2009-06-10 18:15 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Merlin Moncure <mmoncure@gmail.com>
2009-06-11 13:50 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Tom Lane <tgl@sss.pgh.pa.us>
2009-06-11 14:13 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Merlin Moncure <mmoncure@gmail.com>
@ 2009-06-11 14:26 ` Tom Lane <tgl@sss.pgh.pa.us>
2009-06-12 11:42 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Albe Laurenz <laurenz.albe@wien.gv.at>
0 siblings, 1 reply; 632+ messages in thread
From: Tom Lane @ 2009-06-11 14:26 UTC (permalink / raw)
To: Merlin Moncure <mmoncure@gmail.com>; +Cc: Albe Laurenz <laurenz.albe@wien.gv.at>; Andrew Dunstan <andrew@dunslane.net>; pgsql-hackers; ac@esilo.com
Merlin Moncure <mmoncure@gmail.com> writes:
> On Thu, Jun 11, 2009 at 9:50 AM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
>> Where are we on this?
> waiting on a patch? Albe? (or should I do it myself?)
I thought the proposed patch was just "remove the special case for AIX
in src/backend/libpq/ip.c".
regards, tom lane
^ permalink raw reply [nested|flat] 632+ messages in thread
* Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX
2009-06-09 15:57 Problem with listen_addresses = '*' on 8.4beta2 on AIX Albe Laurenz <laurenz.albe@wien.gv.at>
2009-06-09 20:27 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Tom Lane <tgl@sss.pgh.pa.us>
2009-06-09 21:17 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Andrew Dunstan <andrew@dunslane.net>
2009-06-09 21:24 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Tom Lane <tgl@sss.pgh.pa.us>
2009-06-09 21:38 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Merlin Moncure <mmoncure@gmail.com>
2009-06-09 22:11 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Tom Lane <tgl@sss.pgh.pa.us>
2009-06-10 07:38 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Albe Laurenz <laurenz.albe@wien.gv.at>
2009-06-10 13:15 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Merlin Moncure <mmoncure@gmail.com>
2009-06-10 15:38 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Albe Laurenz <laurenz.albe@wien.gv.at>
2009-06-10 16:13 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Tom Lane <tgl@sss.pgh.pa.us>
2009-06-10 18:15 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Merlin Moncure <mmoncure@gmail.com>
2009-06-11 13:50 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Tom Lane <tgl@sss.pgh.pa.us>
2009-06-11 14:13 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Merlin Moncure <mmoncure@gmail.com>
2009-06-11 14:26 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Tom Lane <tgl@sss.pgh.pa.us>
@ 2009-06-12 11:42 ` Albe Laurenz <laurenz.albe@wien.gv.at>
2009-06-12 12:02 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Merlin Moncure <mmoncure@gmail.com>
2009-06-12 14:32 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 2 replies; 632+ messages in thread
From: Albe Laurenz @ 2009-06-12 11:42 UTC (permalink / raw)
To: Tom Lane *EXTERN* <tgl@sss.pgh.pa.us>; Merlin Moncure <mmoncure@gmail.com>; +Cc: Andrew Dunstan <andrew@dunslane.net>; pgsql-hackers; ac@esilo.com
Tom Lane wrote:
>> On Thu, Jun 11, 2009 at 9:50 AM, Tom Lane wrote:
>>> Where are we on this?
>
>> waiting on a patch? Albe? (or should I do it myself?)
>
> I thought the proposed patch was just "remove the special case for AIX
> in src/backend/libpq/ip.c".
Yes.
The only bugs at IBM that are listed as open are IZ43766 = IZ44519,
and they should not affect us (I looked through the code).
For the record, these result in ai_socktype and ai_protocol being
set to zero in the result.
All other problems should be fixed in AIX 6.1 ML 02, AIX 5.3 ML 09
and AIX 5.2 ML 09. It's hard to say for AIX 5.1 and AIX 4.3.3 as
they are out of support, and bugs that are fixed in current versions
may be unfixed there. On the other hand, the bugs may have been
introduced later. Thus, for AIX 5.1 and AIX 4.3.3 we should request
that the last Maintenance Level be installed (ML 09 for AIX 5.1
and ML 11 for 4.3.3).
I am waiting for Merlin's report whether getaddrinfo(3) works on his
AIX 4.3.3 after upgrading to ML 11.
I'll attach a small C program I wrote for my convenience to test
different getaddrinfo calls that occur in PostgreSQL code.
After we have word from Merlin, I'd write a patch that changes
src/backend/libpq/ip.c and src/frontend/libpq/ip.c to undo the AIX hack
and adds documentation to section 15.8.1 that states the recommended
fix levels per AIX version.
I won't get to do that before Monday though, so if somebody can do
it before that, go ahead.
Which raises a final question for me:
The documentation mentions support from 4.3 on, and there are specific
comments for 4.3.2.
We can't say anything for versions before 4.3.3, can we?
Should we drop versions < 4.3.3 even if Merlin reports success for 4.3.3?
Yours,
Laurenz Albe
Attachments:
[application/octet-stream] test_getaddrinfo.c (3.0K, ../../D960CB61B694CF459DCFB4B0128514C202FF664A@exadv11.host.magwien.gv.at/2-test_getaddrinfo.c)
download
^ permalink raw reply [nested|flat] 632+ messages in thread
* Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX
2009-06-09 15:57 Problem with listen_addresses = '*' on 8.4beta2 on AIX Albe Laurenz <laurenz.albe@wien.gv.at>
2009-06-09 20:27 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Tom Lane <tgl@sss.pgh.pa.us>
2009-06-09 21:17 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Andrew Dunstan <andrew@dunslane.net>
2009-06-09 21:24 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Tom Lane <tgl@sss.pgh.pa.us>
2009-06-09 21:38 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Merlin Moncure <mmoncure@gmail.com>
2009-06-09 22:11 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Tom Lane <tgl@sss.pgh.pa.us>
2009-06-10 07:38 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Albe Laurenz <laurenz.albe@wien.gv.at>
2009-06-10 13:15 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Merlin Moncure <mmoncure@gmail.com>
2009-06-10 15:38 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Albe Laurenz <laurenz.albe@wien.gv.at>
2009-06-10 16:13 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Tom Lane <tgl@sss.pgh.pa.us>
2009-06-10 18:15 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Merlin Moncure <mmoncure@gmail.com>
2009-06-11 13:50 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Tom Lane <tgl@sss.pgh.pa.us>
2009-06-11 14:13 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Merlin Moncure <mmoncure@gmail.com>
2009-06-11 14:26 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Tom Lane <tgl@sss.pgh.pa.us>
2009-06-12 11:42 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Albe Laurenz <laurenz.albe@wien.gv.at>
@ 2009-06-12 12:02 ` Merlin Moncure <mmoncure@gmail.com>
1 sibling, 0 replies; 632+ messages in thread
From: Merlin Moncure @ 2009-06-12 12:02 UTC (permalink / raw)
To: Albe Laurenz <laurenz.albe@wien.gv.at>; +Cc: Tom Lane *EXTERN* <tgl@sss.pgh.pa.us>; Andrew Dunstan <andrew@dunslane.net>; pgsql-hackers; ac@esilo.com
On Fri, Jun 12, 2009 at 7:42 AM, Albe Laurenz<laurenz.albe@wien.gv.at> wrote:
> Which raises a final question for me:
> The documentation mentions support from 4.3 on, and there are specific
> comments for 4.3.2.
> We can't say anything for versions before 4.3.3, can we?
> Should we drop versions < 4.3.3 even if Merlin reports success for 4.3.3?
4.3.3 is working fine.
merlin
^ permalink raw reply [nested|flat] 632+ messages in thread
* Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX
2009-06-09 15:57 Problem with listen_addresses = '*' on 8.4beta2 on AIX Albe Laurenz <laurenz.albe@wien.gv.at>
2009-06-09 20:27 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Tom Lane <tgl@sss.pgh.pa.us>
2009-06-09 21:17 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Andrew Dunstan <andrew@dunslane.net>
2009-06-09 21:24 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Tom Lane <tgl@sss.pgh.pa.us>
2009-06-09 21:38 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Merlin Moncure <mmoncure@gmail.com>
2009-06-09 22:11 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Tom Lane <tgl@sss.pgh.pa.us>
2009-06-10 07:38 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Albe Laurenz <laurenz.albe@wien.gv.at>
2009-06-10 13:15 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Merlin Moncure <mmoncure@gmail.com>
2009-06-10 15:38 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Albe Laurenz <laurenz.albe@wien.gv.at>
2009-06-10 16:13 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Tom Lane <tgl@sss.pgh.pa.us>
2009-06-10 18:15 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Merlin Moncure <mmoncure@gmail.com>
2009-06-11 13:50 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Tom Lane <tgl@sss.pgh.pa.us>
2009-06-11 14:13 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Merlin Moncure <mmoncure@gmail.com>
2009-06-11 14:26 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Tom Lane <tgl@sss.pgh.pa.us>
2009-06-12 11:42 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Albe Laurenz <laurenz.albe@wien.gv.at>
@ 2009-06-12 14:32 ` Tom Lane <tgl@sss.pgh.pa.us>
2009-06-12 14:59 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Albe Laurenz <laurenz.albe@wien.gv.at>
1 sibling, 1 reply; 632+ messages in thread
From: Tom Lane @ 2009-06-12 14:32 UTC (permalink / raw)
To: Albe Laurenz <laurenz.albe@wien.gv.at>; +Cc: Merlin Moncure <mmoncure@gmail.com>; Andrew Dunstan <andrew@dunslane.net>; pgsql-hackers; ac@esilo.com
"Albe Laurenz" <laurenz.albe@wien.gv.at> writes:
> After we have word from Merlin, I'd write a patch that changes
> src/backend/libpq/ip.c and src/frontend/libpq/ip.c to undo the AIX hack
> and adds documentation to section 15.8.1 that states the recommended
> fix levels per AIX version.
> I won't get to do that before Monday though, so if somebody can do
> it before that, go ahead.
The code change is already made for RC1, but if you want to send in a
patch to improve the docs, feel free. I left it with just a vague
recommendation to update to the latest fixpack:
http://developer.postgresql.org/pgdocs/postgres/installation-platform-notes.html#INSTALLATION-NOTES-...
regards, tom lane
^ permalink raw reply [nested|flat] 632+ messages in thread
* Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX
2009-06-09 15:57 Problem with listen_addresses = '*' on 8.4beta2 on AIX Albe Laurenz <laurenz.albe@wien.gv.at>
2009-06-09 20:27 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Tom Lane <tgl@sss.pgh.pa.us>
2009-06-09 21:17 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Andrew Dunstan <andrew@dunslane.net>
2009-06-09 21:24 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Tom Lane <tgl@sss.pgh.pa.us>
2009-06-09 21:38 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Merlin Moncure <mmoncure@gmail.com>
2009-06-09 22:11 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Tom Lane <tgl@sss.pgh.pa.us>
2009-06-10 07:38 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Albe Laurenz <laurenz.albe@wien.gv.at>
2009-06-10 13:15 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Merlin Moncure <mmoncure@gmail.com>
2009-06-10 15:38 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Albe Laurenz <laurenz.albe@wien.gv.at>
2009-06-10 16:13 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Tom Lane <tgl@sss.pgh.pa.us>
2009-06-10 18:15 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Merlin Moncure <mmoncure@gmail.com>
2009-06-11 13:50 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Tom Lane <tgl@sss.pgh.pa.us>
2009-06-11 14:13 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Merlin Moncure <mmoncure@gmail.com>
2009-06-11 14:26 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Tom Lane <tgl@sss.pgh.pa.us>
2009-06-12 11:42 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Albe Laurenz <laurenz.albe@wien.gv.at>
2009-06-12 14:32 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Tom Lane <tgl@sss.pgh.pa.us>
@ 2009-06-12 14:59 ` Albe Laurenz <laurenz.albe@wien.gv.at>
2009-06-12 15:54 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 632+ messages in thread
From: Albe Laurenz @ 2009-06-12 14:59 UTC (permalink / raw)
To: Tom Lane *EXTERN* <tgl@sss.pgh.pa.us>; +Cc: Merlin Moncure <mmoncure@gmail.com>; Andrew Dunstan <andrew@dunslane.net>; pgsql-hackers; ac@esilo.com
Tom Lane wrote:
> The code change is already made for RC1, but if you want to send in a
> patch to improve the docs, feel free. I left it with just a vague
> recommendation to update to the latest fixpack:
> http://developer.postgresql.org/pgdocs/postgres/installation-platform-notes.html#INSTALLATION-NOTES-...
The attached patch states that we support 4.3.3 to 6.1, removes the
comment for version 4.3.2 and adds a table of minimum recommended fix
levels for AIX.
Use all or parts of it as you think fit.
Yours,
Laurenz Albe
Attachments:
[application/octet-stream] aixdoc.patch (3.2K, ../../D960CB61B694CF459DCFB4B0128514C202FF664C@exadv11.host.magwien.gv.at/2-aixdoc.patch)
download | inline diff:
*** postgresql-8.4.orig/doc/src/sgml/installation.sgml 2009-06-12 16:47:15.000000000 +0200
--- postgresql-8.4/doc/src/sgml/installation.sgml 2009-06-12 16:46:03.000000000 +0200
***************
*** 2054,2060 ****
<para>
PostgreSQL on AIX works, but getting it installed properly can be
! challenging. Both AIX version 4.3 and 5.3 are supported in
theory. You can use GCC or the native IBM compiler xlc. In
general, using recent versions of AIX and PostgreSQL helps. Check
the build farm for up to date information about which versions of
--- 2054,2060 ----
<para>
PostgreSQL on AIX works, but getting it installed properly can be
! challenging. AIX versions from 4.3.3 to 6.1 are supported in
theory. You can use GCC or the native IBM compiler xlc. In
general, using recent versions of AIX and PostgreSQL helps. Check
the build farm for up to date information about which versions of
***************
*** 2086,2103 ****
</para>
<sect3>
- <title>AIX 4.3.2</title>
-
- <para>
- On AIX 4.3.2, you need <filename>libm.a</filename> that is in the
- fileset <literal>bos.adt.libm</>. Try the following command:
- <screen>
- $ lslpp -l bos.adt.libm
- </screen>
- </para>
- </sect3>
-
- <sect3>
<title>GCC issues</title>
<para>
--- 2086,2091 ----
***************
*** 2150,2156 ****
<filename>pg_hba.conf</>, etc. Older versions of AIX have assorted
bugs in this function. If you have problems related to these settings,
updating to the latest fix pack for your AIX release should fix it.
! </para>
<!-- http://archives.postgresql.org/message-id/6064jt6cfm.fsf_-_@dba2.int.libertyrms.com -->
--- 2138,2189 ----
<filename>pg_hba.conf</>, etc. Older versions of AIX have assorted
bugs in this function. If you have problems related to these settings,
updating to the latest fix pack for your AIX release should fix it.
! To check your current level, use
! <quote><command>oslevel -r</command></quote> from AIX 4.3.3 to
! AIX 5.2 ML 7 and <quote><command>oslevel -s</command></quote> above.
! </para>
!
! <table id="AIX-fixlevels">
! <title>
! Minimum recommended <systemitem class="osname">AIX</systemitem> fix levels
! </title>
!
! <tgroup cols="2">
! <thead>
! <row>
! <entry>AIX version</entry>
! <entry>fix level</entry>
! </row>
! </thead>
!
! <tbody>
! <row>
! <entry>AIX 4.3.3</entry>
! <entry>Maintenance Level 11 + post ML11 bundle</entry>
! </row>
!
! <row>
! <entry>AIX 5.1</entry>
! <entry>Maintenance Level 9 + post ML9 bundle</entry>
! </row>
!
! <row>
! <entry>AIX 5.2</entry>
! <entry>Technology Level 10 Service Pack 3</entry>
! </row>
!
! <row>
! <entry>AIX 5.3</entry>
! <entry>Technology Level 7</entry>
! </row>
!
! <row>
! <entry>AIX 6.1</entry>
! <entry>Base Level</entry>
! </row>
! </tbody>
! </tgroup>
! </table>
<!-- http://archives.postgresql.org/message-id/6064jt6cfm.fsf_-_@dba2.int.libertyrms.com -->
^ permalink raw reply [nested|flat] 632+ messages in thread
* Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX
2009-06-09 15:57 Problem with listen_addresses = '*' on 8.4beta2 on AIX Albe Laurenz <laurenz.albe@wien.gv.at>
2009-06-09 20:27 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Tom Lane <tgl@sss.pgh.pa.us>
2009-06-09 21:17 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Andrew Dunstan <andrew@dunslane.net>
2009-06-09 21:24 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Tom Lane <tgl@sss.pgh.pa.us>
2009-06-09 21:38 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Merlin Moncure <mmoncure@gmail.com>
2009-06-09 22:11 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Tom Lane <tgl@sss.pgh.pa.us>
2009-06-10 07:38 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Albe Laurenz <laurenz.albe@wien.gv.at>
2009-06-10 13:15 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Merlin Moncure <mmoncure@gmail.com>
2009-06-10 15:38 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Albe Laurenz <laurenz.albe@wien.gv.at>
2009-06-10 16:13 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Tom Lane <tgl@sss.pgh.pa.us>
2009-06-10 18:15 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Merlin Moncure <mmoncure@gmail.com>
2009-06-11 13:50 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Tom Lane <tgl@sss.pgh.pa.us>
2009-06-11 14:13 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Merlin Moncure <mmoncure@gmail.com>
2009-06-11 14:26 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Tom Lane <tgl@sss.pgh.pa.us>
2009-06-12 11:42 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Albe Laurenz <laurenz.albe@wien.gv.at>
2009-06-12 14:32 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Tom Lane <tgl@sss.pgh.pa.us>
2009-06-12 14:59 ` Re: Problem with listen_addresses = '*' on 8.4beta2 on AIX Albe Laurenz <laurenz.albe@wien.gv.at>
@ 2009-06-12 15:54 ` Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 632+ messages in thread
From: Tom Lane @ 2009-06-12 15:54 UTC (permalink / raw)
To: Albe Laurenz <laurenz.albe@wien.gv.at>; +Cc: Merlin Moncure <mmoncure@gmail.com>; Andrew Dunstan <andrew@dunslane.net>; pgsql-hackers; ac@esilo.com
"Albe Laurenz" <laurenz.albe@wien.gv.at> writes:
> The attached patch states that we support 4.3.3 to 6.1, removes the
> comment for version 4.3.2 and adds a table of minimum recommended fix
> levels for AIX.
Applied with a bit of additional wordsmithing. Thanks!
regards, tom lane
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v2 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index c8ba94303f1..c23e0a6e260 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index e1ac4bf4c0b..42bce35c887 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2072,16 +2072,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--ChIdkGVrtcKYZbRk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v2-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v1 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-11-14 16:28 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-11-14 16:28 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index b89278ef032..8a12bd5f65a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 63eb2548da1..67810ea489a 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2327,16 +2327,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid,
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 962396bae10..5585381bc8c 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--i7+bPtDlPvAbCgMY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v4 2/2] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 8 ++++----
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index f146e14d3d6..75c22405a09 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,11 +670,11 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
-WARNING: database "mydb" must be vacuumed within 39985967 transactions
-DETAIL: Approximately 1.86% of transaction IDs are available for use.
+WARNING: database "mydb" must be vacuumed within 99985967 transactions
+DETAIL: Approximately 4.66% of transaction IDs are available for use.
HINT: To avoid XID assignment failures, execute a database-wide VACUUM in that database.
</programlisting>
@@ -853,7 +853,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 9f5f8e692b8..978ade705e7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2092,16 +2092,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 2921148ceba..1441a051773 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.50.1 (Apple Git-155)
--qmnHGfI3v6dYD6Bi--
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
* [PATCH v3 2/3] Bump transaction ID limit to warn at 100M.
@ 2025-12-12 19:10 Nathan Bossart <nathan@postgresql.org>
0 siblings, 0 replies; 632+ messages in thread
From: Nathan Bossart @ 2025-12-12 19:10 UTC (permalink / raw)
---
doc/src/sgml/maintenance.sgml | 4 ++--
src/backend/access/transam/multixact.c | 6 +++---
src/backend/access/transam/varsup.c | 6 +++---
3 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/doc/src/sgml/maintenance.sgml b/doc/src/sgml/maintenance.sgml
index 257c6a5435d..3960a23ad71 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -670,7 +670,7 @@ SELECT datname, age(datfrozenxid) FROM pg_database;
<para>
If for some reason autovacuum fails to clear old XIDs from a table, the
system will begin to emit warning messages like this when the database's
- oldest XIDs reach forty million transactions from the wraparound point:
+ oldest XIDs reach one hundred million transactions from the wraparound point:
<programlisting>
WARNING: database "mydb" must be vacuumed within 39985967 transactions
@@ -824,7 +824,7 @@ HINT: Execute a database-wide VACUUM in that database.
<para>
Similar to the XID case, if autovacuum fails to clear old MXIDs from a table, the
- system will begin to emit warning messages when the database's oldest MXIDs reach forty
+ system will begin to emit warning messages when the database's oldest MXIDs reach one hundred
million transactions from the wraparound point. And, just as in the XID case, if these
warnings are ignored, the system will refuse to generate new MXIDs once there are fewer
than three million left until wraparound.
diff --git a/src/backend/access/transam/multixact.c b/src/backend/access/transam/multixact.c
index 39e5b691573..27a0baab8c7 100644
--- a/src/backend/access/transam/multixact.c
+++ b/src/backend/access/transam/multixact.c
@@ -2040,16 +2040,16 @@ SetMultiXactIdLimit(MultiXactId oldest_datminmxid, Oid oldest_datoid)
multiStopLimit -= FirstMultiXactId;
/*
- * We'll start complaining loudly when we get within 40M multis of data
+ * We'll start complaining loudly when we get within 100M multis of data
* loss. This is kind of arbitrary, but if you let your gas gauge get
- * down to 2% of full, would you be looking for the next gas station? We
+ * down to 5% of full, would you be looking for the next gas station? We
* need to be fairly liberal about this number because there are lots of
* scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- multiWarnLimit = multiWrapLimit - 40000000;
+ multiWarnLimit = multiWrapLimit - 100000000;
if (multiWarnLimit < FirstMultiXactId)
multiWarnLimit -= FirstMultiXactId;
diff --git a/src/backend/access/transam/varsup.c b/src/backend/access/transam/varsup.c
index 32961b9acab..98aeea96e8a 100644
--- a/src/backend/access/transam/varsup.c
+++ b/src/backend/access/transam/varsup.c
@@ -411,16 +411,16 @@ SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid)
xidStopLimit -= FirstNormalTransactionId;
/*
- * We'll start complaining loudly when we get within 40M transactions of
+ * We'll start complaining loudly when we get within 100M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
- * get down to 2% of full, would you be looking for the next gas station?
+ * get down to 5% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/
- xidWarnLimit = xidWrapLimit - 40000000;
+ xidWarnLimit = xidWrapLimit - 100000000;
if (xidWarnLimit < FirstNormalTransactionId)
xidWarnLimit -= FirstNormalTransactionId;
--
2.39.5 (Apple Git-154)
--hUJBJnA49L/nki7N
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename=v3-0003-Periodically-emit-server-logs-when-fewer-than-500.patch
^ permalink raw reply [nested|flat] 632+ messages in thread
end of thread, other threads:[~2025-12-12 19:10 UTC | newest]
Thread overview: 632+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2009-06-09 15:57 Problem with listen_addresses = '*' on 8.4beta2 on AIX Albe Laurenz <laurenz.albe@wien.gv.at>
2009-06-09 20:27 ` Tom Lane <tgl@sss.pgh.pa.us>
2009-06-09 21:17 ` Andrew Dunstan <andrew@dunslane.net>
2009-06-09 21:24 ` Tom Lane <tgl@sss.pgh.pa.us>
2009-06-09 21:38 ` Merlin Moncure <mmoncure@gmail.com>
2009-06-09 22:11 ` Tom Lane <tgl@sss.pgh.pa.us>
2009-06-10 07:38 ` Albe Laurenz <laurenz.albe@wien.gv.at>
2009-06-10 13:15 ` Merlin Moncure <mmoncure@gmail.com>
2009-06-10 15:38 ` Albe Laurenz <laurenz.albe@wien.gv.at>
2009-06-10 16:13 ` Tom Lane <tgl@sss.pgh.pa.us>
2009-06-10 18:15 ` Merlin Moncure <mmoncure@gmail.com>
2009-06-10 18:19 ` Andrew Dunstan <andrew@dunslane.net>
2009-06-11 13:50 ` Tom Lane <tgl@sss.pgh.pa.us>
2009-06-11 14:13 ` Merlin Moncure <mmoncure@gmail.com>
2009-06-11 14:26 ` Tom Lane <tgl@sss.pgh.pa.us>
2009-06-12 11:42 ` Albe Laurenz <laurenz.albe@wien.gv.at>
2009-06-12 12:02 ` Merlin Moncure <mmoncure@gmail.com>
2009-06-12 14:32 ` Tom Lane <tgl@sss.pgh.pa.us>
2009-06-12 14:59 ` Albe Laurenz <laurenz.albe@wien.gv.at>
2009-06-12 15:54 ` Tom Lane <tgl@sss.pgh.pa.us>
2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH 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 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 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 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 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 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 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 v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH 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 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 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 v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH 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 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 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 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 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 v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH 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 v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH 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 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 v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH 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 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 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 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 v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v1 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH v2 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-11-14 16:28 [PATCH 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 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-12-12 19: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 v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH 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 v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH 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 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 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 v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH 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 v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH 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 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 v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH 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 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 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 v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH 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 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 v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH 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 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 v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH 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 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 v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v3 2/3] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH v4 2/2] Bump transaction ID limit to warn at 100M. Nathan Bossart <nathan@postgresql.org>
2025-12-12 19:10 [PATCH 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 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>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox