Re: XMAX_LOCK_ONLY and XMAX_COMMITTED (fk/multixact code)

> On Nov 24, 2021, at 12:53 PM, Bossart, Nathan <bossartn@amazon.com> wrote:
>
> Another option we might consider is only checking for the
> HEAP_XMAX_LOCK_ONLY bit instead of everything in
> HEAP_XMAX_IS_LOCKED_ONLY.  IIUC everything else is only expected to
> happen for upgrades from v9.2 or earlier, so it might be pretty rare
> at this point.  Otherwise, I'll extract the exact bit pattern for the
> error message as you suggest.

I would prefer to detect and report any "can't happen" bit patterns without regard for how likely the pattern may be.
Thedifficulty is in proving that a bit pattern is disallowed.  Just because you can't find a code path in the current
codebase that would create a pattern doesn't mean it won't have legitimately been created by some past release or
upgradepath.  As such, any prohibitions explicitly in the backend, such as Asserts around a condition, are really
valuable. You can know that the pattern is disallowed, since the server would Assert on it if encountered. 

Aside from that, I don't really buy the argument that databases upgraded from v9.2 or earlier are rare.  Even if
servers*running* v9.2 or earlier are (or become) rare, servers initialized that far back which have been upgraded one
ormore times since then may be common. 

—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company