Re: XMAX_LOCK_ONLY and XMAX_COMMITTED (fk/multixact code)

Поиск
Список
Период
Сортировка
От Mark Dilger
Тема Re: XMAX_LOCK_ONLY and XMAX_COMMITTED (fk/multixact code)
Дата
Msg-id E4BFE1CA-7B09-416E-B6B5-5C0E5F72EDFE@enterprisedb.com
обсуждение исходный текст
Ответ на Re: XMAX_LOCK_ONLY and XMAX_COMMITTED (fk/multixact code)  ("Bossart, Nathan" <bossartn@amazon.com>)
Ответы Re: XMAX_LOCK_ONLY and XMAX_COMMITTED (fk/multixact code)  ("Bossart, Nathan" <bossartn@amazon.com>)
Список pgsql-hackers

> On Nov 23, 2021, at 4:51 PM, Bossart, Nathan <bossartn@amazon.com> wrote:
>
> 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.

I expect that your patch will contain some addition to the amcheck (or pg_amcheck) tests, so if we ever allow some
currentlydisallowed bit combination, we'd be reminded of the need to update amcheck.  So I'm not too worried about that
aspectof this. 

I prefer not to have to get a page (or full file) from a customer when the check reports corruption.  Even assuming
theyare comfortable giving that, which they may not be, it is an extra round trip to the customer asking for stuff. 

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






В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Bossart, Nathan"
Дата:
Сообщение: Re: XMAX_LOCK_ONLY and XMAX_COMMITTED (fk/multixact code)
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations