Re: XMAX_LOCK_ONLY and XMAX_COMMITTED (fk/multixact code)

On 11/25/21, 9:16 AM, "Mark Dilger" <mark.dilger@enterprisedb.com> wrote:
>> 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.
 

Okay, I'll do it that way in the next revision.

Nathan