enhance wraparound warnings

From: Nathan Bossart <nathandbossart(at)gmail(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: enhance wraparound warnings
Date: 2025-11-14 17:05:13
Message-ID: aRdhSSFb9zZH_0zc@nathan
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

varsup.c has the following comment:

/*
* We'll start complaining loudly when we get within 40M transactions of
* data loss. This is kind of arbitrary, but if you let your gas gauge
* get down to 2% of full, would you be looking for the next gas station?
* We need to be fairly liberal about this number because there are lots
* of scenarios where most transactions are done by automatic clients that
* won't pay attention to warnings. (No, we're not gonna make this
* configurable. If you know enough to configure it, you know enough to
* not get in this kind of trouble in the first place.)
*/

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.

* 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".

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

* 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.

Thoughts?

--
nathan

Attachment Content-Type Size
v1-0001-Add-percentage-of-transaction-IDs-that-are-availa.patch text/plain 6.5 KB
v1-0002-Bump-transaction-ID-limit-to-warn-at-100M.patch text/plain 4.2 KB
v1-0003-Perodically-emit-server-logs-when-fewer-than-500M.patch text/plain 11.2 KB

Browse pgsql-hackers by date

  From Date Subject
Next Message David Geier 2025-11-14 17:37:33 Re: Use merge-based matching for MCVs in eqjoinsel
Previous Message Bertrand Drouvot 2025-11-14 16:58:59 Re: PartitionKeyData->partattrs, refactor some 0 to InvalidAttrNumber