On Tue, 21 Oct 2025 at 15:55, Michael Paquier <[email protected]> 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
