Re: XMAX_LOCK_ONLY and XMAX_COMMITTED (fk/multixact code)

> On Nov 23, 2021, at 4:26 PM, Bossart, Nathan <bossartn@amazon.com> wrote:
>
> I've finally gotten started on this, and I've attached a work-in-
> progress patch to gather some early feedback.  I'm specifically
> wondering if there are other places it'd be good to check for these
> unsupported combinations and whether we should use the
> HEAP_XMAX_IS_LOCKED_ONLY macro or just look for the
> HEAP_XMAX_LOCK_ONLY bit.

I have to wonder if, when corruption is reported for conditions like this:

+    if ((ctx->tuphdr->t_infomask & HEAP_XMAX_COMMITTED) &&
+        HEAP_XMAX_IS_LOCKED_ONLY(ctx->tuphdr->t_infomask))

if the first thing we're going to want to know is which branch of the HEAP_XMAX_IS_LOCKED_ONLY macro evaluated true?
Shouldwe split this check to do each branch of the macro separately, such as: 

if (ctx->tuphdr->t_infomask & HEAP_XMAX_COMMITTED)
{
    if (ctx->tuphdr->t_infomask & HEAP_XMAX_LOCK_ONLY)
        ... report something ...
    else if ((ctx->tuphdr->t_infomask & (HEAP_XMAX_IS_MULTI | HEAP_LOCK_MASK)) == HEAP_XMAX_EXCL_LOCK)
        ... report a different thing ...
}

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