[HACKERS] Cleanup: avoid direct use of ip_posid/ip_blkid - Mailing list pgsql-hackers

From Pavan Deolasee
Subject [HACKERS] Cleanup: avoid direct use of ip_posid/ip_blkid
Date
Msg-id CABOikdNuLAXrv9A=dhV+0E5uOwYYDYRUj0e9SuXdY4RVMQUYaQ@mail.gmail.com
Whole thread Raw
Responses Re: [HACKERS] Cleanup: avoid direct use of ip_posid/ip_blkid  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-hackers
Hello All,

I would like to propose the attached patch which removes all direct references to ip_posid and ip_blkid members of ItemPointerData struct and instead use ItemPointerGetOffsetNumber and ItemPointerGetBlockNumber macros respectively to access these members.

My motivation to do this is to try to free-up some bits from ip_posid field, given that it can only be maximum 13-bits long. But even without that, it seems like a good cleanup to me.

One reason why these macros are not always used is because they typically do assert-validation to ensure ip_posid has a valid value. There are a few places in code, especially in GIN and also when we are dealing with user-supplied TIDs when we might get a TID with invalid ip_posid. I've handled that by defining and using separate macros which skip the validation. This doesn't seem any worse than what we are already doing.

make check-world with --enable-tap-tests passes.

Comments/suggestions?

Thanks,
Pavan

--
 Pavan Deolasee                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services
Attachment

pgsql-hackers by date:

Previous
From: Joel Jacobson
Date:
Subject: Re: [HACKERS] GRANT EXECUTE ON FUNCTION foo() TO bar();
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] Replication vs. float timestamps is a disaster