Re: XMAX_LOCK_ONLY and XMAX_COMMITTED (fk/multixact code)

On 11/23/21, 4:59 PM, "Mark Dilger" <mark(dot)dilger(at)enterprisedb(dot)com> wrote:
>> On Nov 23, 2021, at 4:51 PM, Bossart, Nathan <bossartn(at)amazon(dot)com> wrote:
>>
>> This is a good point. Right now, you'd have to manually inspect the
>> infomask field to determine the exact form of the invalid combination.
>> My only worry with this is that we'd want to make sure these checks
>> stayed consistent with the definition of HEAP_XMAX_IS_LOCKED_ONLY in
>> htup_details.h. I'm guessing HEAP_XMAX_IS_LOCKED_ONLY is unlikely to
>> change all that often, though.
>
> I expect that your patch will contain some addition to the amcheck (or pg_amcheck) tests, so if we ever allow some currently disallowed bit combination, we'd be reminded of the need to update amcheck. So I'm not too worried about that aspect of this.
>
> I prefer not to have to get a page (or full file) from a customer when the check reports corruption. Even assuming they are comfortable giving that, which they may not be, it is an extra round trip to the customer asking for stuff.

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.

Nathan