Re: making relfilenodes 56 bits - Mailing list pgsql-hackers

From Tom Lane
Subject Re: making relfilenodes 56 bits
Date
Msg-id 4154748.1659125134@sss.pgh.pa.us
Whole thread Raw
In response to Re: making relfilenodes 56 bits  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: making relfilenodes 56 bits
List pgsql-hackers
Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> On 2022-Jul-29, Robert Haas wrote:
>> Yeah, if we think it's OK to pass around structs, then that seems like
>> the right solution. Otherwise functions that take RelFileLocator
>> should be changed to take const RelFileLocator * and we should adjust
>> elsewhere accordingly.

> We do that in other places.  See get_object_address() for another
> example.  Now, I don't see *why* they do it.

If it's a big struct then avoiding copying it is good; but RelFileLocator
isn't that big.

While researching that statement I did happen to notice that no one has
bothered to update the comment immediately above struct RelFileLocator,
and it is something that absolutely does require attention if there
are plans to make RelFileNumber something other than 32 bits.

 * Note: various places use RelFileLocator in hashtable keys.  Therefore,
 * there *must not* be any unused padding bytes in this struct.  That
 * should be safe as long as all the fields are of type Oid.
 */
typedef struct RelFileLocator
{
    Oid            spcOid;            /* tablespace */
    Oid            dbOid;             /* database */
    RelFileNumber  relNumber;         /* relation */
} RelFileLocator;

            regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg15b2: large objects lost on upgrade
Next
From: Tom Lane
Date:
Subject: Re: making relfilenodes 56 bits