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
