README.tuplock says:
> There is one exception
> here: since infomask space is limited, we do not provide a separate bit
> for SELECT FOR SHARE, so we have to use the extended info in a MultiXact in
> that case. (The other cases, SELECT FOR UPDATE and SELECT FOR KEY SHARE, are
> presumably more commonly used due to being the standards-mandated locking
> mechanism, or heavily used by the RI code, so we want to provide fast paths
> for those.)
But looking at the explanations of the infomask bits further down (as
updated in commit cdbdc4382743fcfabb3437ea7c4d103adaa01324), as well
as the actual code for locking a not-yet-locked tuple in
compute_new_xmax_infomask(), this doesn't seem to be true. Was this an
oversight?
