Re: BRIN: Prevent the heapblk overflow during index summarization on very large tables resulting in an infinite loop - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: BRIN: Prevent the heapblk overflow during index summarization on very large tables resulting in an infinite loop
Date
Msg-id aPb2L45nioBc3ldL@paquier.xyz
Whole thread Raw
In response to Re: BRIN: Prevent the heapblk overflow during index summarization on very large tables resulting in an infinite loop  (sunil s <sunilfeb26@gmail.com>)
Responses Re: BRIN: Prevent the heapblk overflow during index summarization on very large tables resulting in an infinite loop
List pgsql-hackers
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

Attachment

pgsql-hackers by date:

Previous
From: Chao Li
Date:
Subject: Re: Add \pset options for boolean value display
Next
From: Richard Guo
Date:
Subject: Re: Inconsistent Behavior of GROUP BY ROLLUP in v17 vs master