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