Re: XMAX_LOCK_ONLY and XMAX_COMMITTED (fk/multixact code)

Поиск
Список
Период
Сортировка
От Bossart, Nathan
Тема Re: XMAX_LOCK_ONLY and XMAX_COMMITTED (fk/multixact code)
Дата
Msg-id 15CBE910-AE91-4F92-8143-65FD4EF3FA9C@amazon.com
обсуждение исходный текст
Ответ на Re: XMAX_LOCK_ONLY and XMAX_COMMITTED (fk/multixact code)  (Mark Dilger <mark.dilger@enterprisedb.com>)
Ответы Re: XMAX_LOCK_ONLY and XMAX_COMMITTED (fk/multixact code)  (Mark Dilger <mark.dilger@enterprisedb.com>)
Список 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 по дате отправления:

Предыдущее
От: Greg Nancarrow
Дата:
Сообщение: Re: Windows build warnings
Следующее
От: Mark Dilger
Дата:
Сообщение: Re: XMAX_LOCK_ONLY and XMAX_COMMITTED (fk/multixact code)