Re: XMAX_LOCK_ONLY and XMAX_COMMITTED (fk/multixact code) - Mailing list pgsql-hackers

From Bossart, Nathan
Subject Re: XMAX_LOCK_ONLY and XMAX_COMMITTED (fk/multixact code)
Date
Msg-id 5F86D901-EF66-465A-A7B7-3D789C83F6DC@amazon.com
Whole thread Raw
In response to Re: XMAX_LOCK_ONLY and XMAX_COMMITTED (fk/multixact code)  (Mark Dilger <mark.dilger@enterprisedb.com>)
Responses Re: XMAX_LOCK_ONLY and XMAX_COMMITTED (fk/multixact code)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Rename dead_tuples to dead_items in vacuumlazy.c
Next
From: Bruce Momjian
Date:
Subject: Re: Suggestion: Unified options API. Need help from core team