On 11/25/21, 9:16 AM, "Mark Dilger" <mark.dil...@enterprisedb.com> wrote:
>> On Nov 24, 2021, at 12:53 PM, Bossart, Nathan <bossa...@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.  The difficulty is in proving that a 
>bit pattern is disallowed.  Just because you can't find a code path in the 
>current code base that would create a pattern doesn't mean it won't have 
>legitimately been created by some past release or upgrade path.  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 
> or more times since then may be common.

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

Nathan

Reply via email to