Re: XMAX_LOCK_ONLY and XMAX_COMMITTED (fk/multixact code)

Поиск
Список
Период
Сортировка
От Nathan Bossart
Тема Re: XMAX_LOCK_ONLY and XMAX_COMMITTED (fk/multixact code)
Дата
Msg-id 20230202173348.GA3744577@nathanxps13
обсуждение исходный текст
Ответ на Re: XMAX_LOCK_ONLY and XMAX_COMMITTED (fk/multixact code)  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
On Thu, Feb 02, 2023 at 06:59:51AM -0800, Andres Freund wrote:
> On 2022-09-20 11:32:02 -0700, Nathan Bossart wrote:
>> Note that this change also disallows XMAX_COMMITTED together with
>> the special pre-v9.3 locked-only bit pattern that
>> HEAP_XMAX_IS_LOCKED_ONLY checks for.  This locked-only bit pattern
>> may still be present on servers pg_upgraded from pre-v9.3 versions.
> 
> Given that fact, that aspect at least seems to be not viable?

AFAICT from looking at the v9.2 code, the same idea holds true for this
special bit pattern.  I only see HEAP_XMAX_INVALID set when one of the
infomask lock bits is set, and those bits now correspond to
HEAP_XMAX_LOCK_ONLY and HEAP_XMAX_EXCL_LOCK (which are both covered by the
HEAP_XMAX_IS_LOCKED_ONLY macro).  Of course, I could be missing something.
Do you think we should limit this to the v9.3+ bit pattern?

-- 
Nathan Bossart
Amazon Web Services: https://aws.amazon.com



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

Предыдущее
От: Melanie Plageman
Дата:
Сообщение: Re: heapgettup refactoring
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: Schema variables - new implementation for Postgres 15 (typo)