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

On Tue, 21 Oct 2025 at 15:55, Michael Paquier <michael@paquier.xyz> wrote:
> 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.

I'd leave it as uint64. There's no reason to mixup the signedness
between these two variables.

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

I wasn't a fan of that change either. I suggested "We make use of
uint64 for heapBlk as a BlockNumber could wrap for tables with close
to 2^32 pages.", but that's not what happened.

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

I don't think totalpages being int64 is an argument to make the heapBlk int64.

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

I suggested that too, but ...

I'm happy to finish this one off. I was leaving it for Tomas to
comment, but I think he'll be busy with pgconf.eu for the next few
days.

David