Re: XMAX_LOCK_ONLY and XMAX_COMMITTED (fk/multixact code)

> On Dec 1, 2021, at 10:59 AM, Bossart, Nathan <bossartn(at)amazon(dot)com> wrote:
>
> here is a v3

It took a while for me to get to this....

@@ -1304,33 +1370,46 @@ HeapTupleSatisfiesVacuumHorizon(HeapTuple htup, Buffer buffer, TransactionId *de

if (HEAP_XMAX_IS_LOCKED_ONLY(tuple->t_infomask))
{
+ if (unlikely(tuple->t_infomask & HEAP_XMAX_COMMITTED))
+ {
+ if (tuple->t_infomask & HEAP_XMAX_LOCK_ONLY)
+ ereport(ERROR,
+ (errcode(ERRCODE_DATA_CORRUPTED),
+ errmsg_internal("found tuple with HEAP_XMAX_COMMITTED "
+ "and HEAP_XMAX_LOCK_ONLY")));
+
+ /* pre-v9.3 lock-only bit pattern */
+ ereport(ERROR,
+ (errcode(ERRCODE_DATA_CORRUPTED),
+ errmsg_internal("found tuple with HEAP_XMAX_COMMITTED and"
+ "HEAP_XMAX_EXCL_LOCK set and "
+ "HEAP_XMAX_IS_MULTI unset")));
+ }
+

I find this bit hard to understand. Does the comment mean to suggest that the *upgrade* process should have eliminated all pre-v9.3 bit patterns, and therefore any such existing patterns are certainly corruption, or does it mean that data written by pre-v9.3 servers (and not subsequently updated) is defined as corrupt, or .... ?

I am not complaining that the logic is wrong, just trying to wrap my head around what the comment means.

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