On Mon, Jan 31, 2022 at 9:37 AM Dilip Kumar <dilipbal...@gmail.com> wrote: > I agree that we are using 8 bytes unsigned int multiple places in code > as uint64. But I don't see it as an exposed data type and not used as > part of any exposed function. But we will have to use the relfilenode > in the exposed c function e.g. > binary_upgrade_set_next_heap_relfilenode().
Oh, I thought we were talking about the C data type uint8 i.e. an 8-bit unsigned integer. Which in retrospect was a dumb thought because you said you wanted to store the relfilenode AND the fork number there, which only make sense if you were talking about SQL data types rather than C data types. It is confusing that we have an SQL data type called int8 and a C data type called int8 and they're not the same. But if you're talking about SQL data types, why? pg_class only stores the relfilenode and not the fork number currently, and I don't see why that would change. I think that the data type for the relfilenode column would change to a 64-bit signed integer (i.e. bigint or int8) that only ever uses the low-order 56 bits, and then when you need to store a relfilenode and a fork number in the same 8-byte quantity you'd do that using either a struct with bit fields or by something like combined = ((uint64) signed_representation_of_relfilenode) | (((int) forknumber) << 56); -- Robert Haas EDB: http://www.enterprisedb.com