Re: Preventing indirection for IndexPageGetOpaque for known-size page special areas

On Fri, 1 Apr 2022 at 07:38, Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> On Thu, Mar 31, 2022 at 12:09:35PM +0200, Matthias van de Meent wrote:
> > PageInit MAXALIGNs the size of the special area that it receives as an
> > argument; so any changes to the page header that would misalign the
> > value would be AM-specific; in which case it is quite unlikely that
> > this is the right accessor for your page's special area.
>
> Right. I'd still be tempted to keep that per-AM rather than making
> the checks deeper with one extra macro layer in the page header or
> with a different macro that would depend on the opaque type, though.
> Like in the attached, for example.

I see. I still would like it better if the access could use this
statically determined offset: your opaque-macros.patch doesn't fix the
out-of-bound read/write scenariofor non-assert builds, nor does it
remove the unneeded indirection through the page header that I was
trying to remove.

Even in assert-enabled builds; with my proposed changes the code paths
for checking the header value and the use of the special area can be
executed independently, which allows for parallel (pre-)fetching of
the page header and special area, as opposed to the current sequential
load order due to the required use of pd_special.

-Matthias