Horton

Re: BRIN: Prevent the heapblk overflow during index summarization on very large tables resulting in an infinite loop

Michael Paquier <michael@paquier.xyz>

View thread
From: Michael Paquier <michael@paquier.xyz>
To: sunil s <sunilfeb26@gmail.com>
Cc: David Rowley <dgrowleyml@gmail.com>, pgsql-hackers@lists.postgresql.org
Date: 2025-10-21T02:55:43Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Fix BRIN 32-bit counter wrap issue with huge tables

  2. Fix integer overflow bug in GiST buffering build calculations.

On Mon, Oct 20, 2025 at 03:11:01PM +0530, sunil s wrote:
> Thanks, David, for providing feedback on the changes.
> I’ve addressed your comments and attached a rebased patch.

Using signed or unsigned is not going to matter much at the end.  We
would be far from the count even if the number is signed.

+	 * Since heapBlk is incremented by opaque->bo_pagesPerRange, it can exceed
+	 * the maximum 32-bit limit (2^32) on very large tables, potentially causing
+	 * the loop to become infinite.
+	 *
+	 * To prevent this overflow, the counter must use a 64-bit type, ensuring it
+	 * can handle cases where nblocks approaches 2^32.

2^32 is mentioned twice.  A simpler suggestion:
Since heapBlk is incremented by opaque->bo_pagesPerRange, it could
exceed the maximum 32-bit limit (2^32) on very large tables and
wraparound.  The counter must be 64 bits wide for this reason.

Like totalpages, there is an argument about consistency based on the
result type of bringetbitmap().  It's minor, still.

It would be simpler to switch "pageno" to be 64-bit wide as well,
rather than casting it back to BlockNumber.
--
Michael