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)
|
Список | 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 по дате отправления: