Subject: Re: enhance wraparound warnings

From: Shinya Kato <[email-masked]>
Date: Wed, 18 Feb 2026 16:16:16 +0900

On Sat, Nov 15, 2025 at 2:05 AM Nathan Bossart <[email-masked]> wrote:
> I don't know about you, but I start getting antsy around a quarter tank.
> In any case, I'm told that even 40M transactions aren't enough time to
> react these days.  Attached are a few patches to enhance the wraparound
> warnings.

Thank you for the patch!

> * 0001 adds a "percent remaining" detail message to the existing WARNING.
> The idea is that "1.86% of transaction IDs" is both easier to understand
> and better indicates urgency than "39985967 transactions".

I like this idea and this is helpful information for DBA. 0001 looks good to me.

> * 0002 bumps the warning limit from 40M to 100M to give folks some more
> time to react.

I don't have a strong opinion on whether 100M is the right value, but
I noticed a documentation issue in 0002.

<programlisting>
WARNING:  database "mydb" must be vacuumed within 39985967 transactions
DETAIL:  Approximately 1.86% of transaction IDs are available for use.
HINT:  To avoid XID assignment failures, execute a database-wide
VACUUM in that database.
</programlisting>

In maintenance.sgml, above "39985967" and "1.86%" should be updated.

> * 0003 adds an early warning system for when fewer than 500M transactions
> remain.  This system sends a LOG only to the server log every 1M
> transactions.  The hope is that this gets someone's attention sooner
> without flooding the application and server log.

I'm not sure 0003 is worth the added complexity. It adds a new field
to TransamVariablesData and a modulo check in GetNewTransactionId(),
which is a hot path. DBAs who need early warning can already monitor
age(datfrozenxid) with more flexible thresholds.

-- 
Best regards,
Shinya Kato
NTT OSS Center

---

From: Nathan Bossart <[email-masked]>
Date: Tue, 3 Mar 2026 14:31:25 -0600

>> react these days.  Attached are a few patches to enhance the wraparound

Thanks for reviewing.

> In maintenance.sgml, above "39985967" and "1.86%" should be updated.

Fixed.

> age(datfrozenxid) with more flexible thresholds.

Yeah, looking at this one again, I'm less sure it's worth pursuing.  I've
removed it.

-- 
nathan

---

From: Nathan Bossart <[email-masked]>
Date: Fri, 6 Mar 2026 16:15:12 -0600

Barring additional feedback or objections, I'm planning to commit this in
the next week or two.

-- 
nathan

---

From: wenhui qiu <[email-masked]>
Date: Mon, 9 Mar 2026 20:08:54 +0800

Hi Nathan Bossart
> Barring additional feedback or objections, I'm planning to commit this in
Thank you for working on this. The path LGTM,But I have a small request,There
are many reasons why the table's age can’t be frozen. Now have a path that
can report the reason to users(https://commitfest.postgresql.org/patch/6188/).
Would you be interested in reviewing it? I think we should tell users the
root cause of why the age can’t be reduced, so they can clearly understand
where the issue is.I think we should not only tell users that the XID is
close to wraparound, but also report why this causes the table‘s age to be
unable to freeze.

Thanks

---

From: Nathan Bossart <[email-masked]>
Date: Fri, 20 Mar 2026 14:16:42 -0500

On Mon, Mar 09, 2026 at 08:08:54PM +0800, wenhui qiu wrote:
> Thank you for working on this. The path LGTM,...

Thanks for looking.  Committed.

> ...But I have a small request,There

Thanks for alerting me to this patch.

-- 
nathan

---

From: Fujii Masao <[email-masked]>
Date: Sat, 20 Jun 2026 03:13:23 +0900

> Thanks for looking.  Committed.

Thanks for working on this feature! I have one comment.

ereport(WARNING,
  (errmsg("database \"%s\" must be vacuumed within %u transactions",
  oldest_datname,
  xidWrapLimit - xid),
+ errdetail("Approximately %.2f%% of transaction IDs are available for use.",
+    (double) (xidWrapLimit - xid) / (MaxTransactionId / 2) * 100),
  errhint("To avoid transaction ID assignment failures, execute a
database-wide VACUUM in that database.\n"
  "You might also need to commit or roll back old prepared
transactions, or drop stale replication slots.")));

The new DETAIL messages for XID and MultiXactId wraparound warnings
seem misleading.

The percentage is calculated as (xidWrapLimit - xid) divided by half
of the ID space. This represents the remaining ID space before wraparound,
not the percentage of IDs that are still available for use. Since
PostgreSQL stops assigning new XIDs/MultiXactIds at the stop limit
before reaching the wraparound limit, the current wording could be
interpreted as overstating how many IDs remain usable.

So, how about changing the wording to match the calculation? For example:

    Approximately XX.XX% of transaction ID space remains before wraparound.

and similarly for MultiXactIds.

Regards,

-- 
Fujii Masao

---

From: Nathan Bossart <[email-masked]>
Date: Fri, 19 Jun 2026 13:43:22 -0500

> and similarly for MultiXactIds.

That seems reasonable to me, thanks.

-- 
nathan

---

From: Fujii Masao <[email-masked]>
Date: Sat, 20 Jun 2026 20:54:03 +0900

> That seems reasonable to me, thanks.

Thanks for the review!

While reading the related log messages again, I noticed that in three of
the four XID wraparound warnings in varsup.c, the HINT still uses "XID"
while the DETAIL message uses "transaction ID". Commit edee0c621de
updated the remaining warning to use "transaction ID",
but seems to have missed the other three. Since using different terms
for the same thing in the DETAIL and HINT messages seems
inconsistent, I included the following changes in the patch. Or would
it be better to do this in a separate patch?

- errdetail("Approximately %.2f%% of transaction IDs are available for use.",
+ errdetail("Approximately %.2f%% of transaction ID space remains
before wraparound.",
     (double) (xidWrapLimit - xid) / (MaxTransactionId / 2) * 100),
- errhint("To avoid XID assignment failures, execute a database-wide
VACUUM in that database.\n"
+ errhint("To avoid transaction ID assignment failures, execute a
database-wide VACUUM in that database.\n"

I also updated the comments in
src/test/modules/xid_wraparound/t/002_limits.pl, which contain
examples of the XID wraparound warnings.

Attached is the updated patch.

While making these changes, I also noticed that although commit
edee0c621de updated the runtime XID wraparound messages to use
"transaction IDs", the corresponding examples and text in
maintenance.sgml still use the older "XID" terminology. I therefore
created an additional patch (0002) to update the documentation to
match the current messages. I think this should be backpatched to v17.

Thought?

Regards,

-- 
Fujii Masao

---

From: Bharath Rupireddy <[email-masked]>
Date: Tue, 23 Jun 2026 21:47:11 -0700

Hi,

> match the current messages. I think this should be backpatched to v17.

I happened to quickly review these patches. TBH, "transaction ID
space" and "MultiXactId space" seem a bit confusing because of the
word "space" - it reads fine without it. Is there a specific reason
for this wording?

Also, why not use "multixact IDs" instead of "MultiXactId"? The latter
reads like an internal structure name or such that might confuse users
reading the docs or error messages.

How about something like the following?

+ errdetail("Approximately %.2f%% of multixact IDs remain before wraparound.",
+ errdetail("Approximately %.2f%% of transaction IDs remain before wraparound.",

-- 
Bharath Rupireddy
Amazon Web Services: https://aws.amazon.com

---

From: Fujii Masao <[email-masked]>
Date: Wed, 24 Jun 2026 21:53:36 +0900

On Wed, Jun 24, 2026 at 1:47 PM Bharath Rupireddy
<[email-masked]> wrote:
> I happened to quickly review these patches.

Thanks for the review!

> TBH, "transaction ID

I was thinking "space" was appropriate here because the message is intended
to express the percentage remaining before wraparound in the ID range.
The documentation also uses expressions such as "normal XID space is ...".

But I'm not a native English speaker, so this wording might be wrong.

> reading the docs or error messages.

I left "MultiXactId" unchanged because several existing log messages
use that term. I don't have any strong objection to changing it to
"multixact ID", which is already used in the documentation. However, if
we do that, I think it's better update all log messages that use
"MultiXactId" for consistency, probably as a separate patch. That seems
more like a v20 item to me, though.

Regards,

-- 
Fujii Masao

---

From: Bharath Rupireddy <[email-masked]>
Date: Thu, 25 Jun 2026 10:19:29 -0700

Hi,

> The documentation also uses expressions such as "normal XID space is ...".

The use there is referring to the whole set of transaction IDs and how
one can visualize the use of them - so "XID space" in that context
seems fine to me.

But the wraparound warnings read better when they say how many more
transaction IDs are left:

+ errdetail("Approximately %.2f%% of MultiXactIds remain before wraparound.",
+ errdetail("Approximately %.2f%% of transaction IDs remain before wraparound.",

> more like a v20 item to me, though.

I'm fine to leave "MultiXactIds" as-is - IMHO, it's not worth the cycles.

---

From: Fujii Masao <[email-masked]>
Date: Fri, 26 Jun 2026 09:51:16 +0900

> + errdetail("Approximately %.2f%% of transaction IDs remain before wraparound.",

Okay, I've updated the patches as suggested. The updated patches are attached.

Regards,

-- 
Fujii Masao

---

From: Kyotaro Horiguchi <[email-masked]>
Date: Fri, 26 Jun 2026 10:55:39 +0900 (JST)

Hello,

At Fri, 26 Jun 2026 09:51:16 +0900, Fujii Masao <[email-masked]> wrote in 
> Okay, I've updated the patches as suggested. The updated patches are attached.

I'm not sure I'm following this correctly, but the explanation above
sounded to me as if the warning should report the number of IDs
remaining before wraparound, e.g. "Approximately N MultiXactIds remain
before wraparound", so I'm a bit confused by the proposed wording.

> + errdetail("Approximately %.2f%% of MultiXactIds remain before wraparound.",

The attached patch adopts that wording. However, I'm not sure how to
interpret it. The value is still expressed as a percentage, but it is
no longer clear what that percentage is relative to.

Whichever approach we choose, I think the wording should be explicit.
If the value is reported as a percentage, then something like "x.xx%
of MultiXactId space remains" seems clearer to me. If it is reported
as a count, then "N MultiXactIds remain" would make more sense.

Regards,

-- 
Kyotaro Horiguchi
NTT Open Source Software Center

---

From: Nathan Bossart <[email-masked]>
Date: Fri, 26 Jun 2026 13:06:36 -0500

> before wraparound", so I'm a bit confused by the proposed wording.

We already report the number of IDs remaining in the WARNING message.  In
v19, I've added a DETAIL message that also reports the percentage
remaining, with the hope that it makes the urgency clearer.

> as a count, then "N MultiXactIds remain" would make more sense.

I find both "percentage of IDs remaining" and "percentage of ID space
remaining" equally clear and have no strong opinion on the matter.

-- 
nathan

---

From: Bharath Rupireddy <[email-masked]>
Date: Fri, 26 Jun 2026 15:18:25 -0700

Hi,

> remaining, with the hope that it makes the urgency clearer.

Yes. For example: WARNING:  database "mydb" must be vacuumed within
99985967 transactions

> remaining" equally clear and have no strong opinion on the matter.

My initial comment was that "IDs remaining" reads more naturally to me
than "ID space remaining," but I'm happy to go with the majority here.
IMHO, no need to spend more cycles on this.