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

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