From: | Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com> |
---|---|
To: | "Bossart, Nathan" <bossartn(at)amazon(dot)com> |
Cc: | 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: | 2021-11-24 00:58:29 |
Message-ID: | E4BFE1CA-7B09-416E-B6B5-5C0E5F72EDFE@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> On Nov 23, 2021, at 4:51 PM, Bossart, Nathan <bossartn(at)amazon(dot)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 currently disallowed bit combination, we'd be reminded of the need to update amcheck. So I'm not too worried about that aspect of this.
I prefer not to have to get a page (or full file) from a customer when the check reports corruption. Even assuming they are 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
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2021-11-24 01:01:20 | Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations |
Previous Message | Bossart, Nathan | 2021-11-24 00:51:15 | Re: XMAX_LOCK_ONLY and XMAX_COMMITTED (fk/multixact code) |