| From: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | "Bossart, Nathan" <bossartn(at)amazon(dot)com>, Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>, Peter Geoghegan <pg(at)bowt(dot)ie>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, "Schneider (AWS), Jeremy" <schnjere(at)amazon(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: XMAX_LOCK_ONLY and XMAX_COMMITTED (fk/multixact code) |
| Date: | 2023-02-02 17:33:48 |
| Message-ID: | 20230202173348.GA3744577@nathanxps13 |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pavel Stehule | 2023-02-02 18:35:28 | Re: Schema variables - new implementation for Postgres 15 (typo) |
| Previous Message | Melanie Plageman | 2023-02-02 17:22:59 | Re: heapgettup refactoring |