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?
