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 15CBE910-AE91-4F92-8143-65FD4EF3FA9C@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/23/21, 4:36 PM, "Mark Dilger" <mark.dilger@enterprisedb.com> wrote:
> 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 ...
> }

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.

Nathan


pgsql-hackers by date:

Previous
From: Greg Nancarrow
Date:
Subject: Re: Windows build warnings
Next
From: Mark Dilger
Date:
Subject: Re: XMAX_LOCK_ONLY and XMAX_COMMITTED (fk/multixact code)