On Sat, Jul 30, 2022 at 1:35 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > > Alvaro Herrera <alvhe...@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.
I think we need to update this comment in the patch where we are making RelFileNumber 64 bits wide. But as such I do not see a problem in using RelFileLocator directly as key because if we make RelFileNumber 64 bits then its structure will already be 8 byte aligned so there should not be any padding. However, if we use some other structure as key which contain RelFileLocator i.e. RelFileLocatorBackend then there will be a problem. So for handling that issue while computing the key size (wherever we have RelFileLocatorBackend as key) I have avoided the padding bytes in size by introducing this new macro[1]. [1] #define SizeOfRelFileLocatorBackend \ (offsetof(RelFileLocatorBackend, backend) + sizeof(BackendId)) -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
