Re: XMAX_LOCK_ONLY and XMAX_COMMITTED (fk/multixact code) - Mailing list pgsql-hackers

From Nathan Bossart
Subject Re: XMAX_LOCK_ONLY and XMAX_COMMITTED (fk/multixact code)
Date
Msg-id 20220322230640.GA1728121@nathanxps13
Whole thread Raw
In response to Re: XMAX_LOCK_ONLY and XMAX_COMMITTED (fk/multixact code)  (Nathan Bossart <nathandbossart@gmail.com>)
Responses Re: XMAX_LOCK_ONLY and XMAX_COMMITTED (fk/multixact code)  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Thu, Mar 17, 2022 at 04:45:28PM -0700, Nathan Bossart wrote:
> I think this one requires some more work, and it needn't be a priority for
> v15, so I've adjusted the commitfest entry to v16 and moved it to the next
> commitfest.

Here is a new patch.  The main differences from v3 are in
heapam_visibility.c.  Specifically, instead of trying to work the infomask
checks into the visibility logic, I added a new function that does a couple
of assertions.  This function is called at the beginning of each visibility
function.

What do folks think?  The options I've considered are 1) not adding any
such checks to heapam_visibility.c, 2) only adding assertions like the
attached patch, or 3) actually using elog(ERROR, ...) when the invalid bit
patterns are detected.  AFAICT (1) is more in line with existing invalid
bit patterns (e.g., XMAX_COMMITTED + XMAX_IS_MULTI).  There are a couple of
scattered assertions, but most code paths don't check for it.  (2) adds
additional checks, but only for --enable-cassert builds.  (3) would add
checks even for non-assert builds, but there would presumably be some
performance cost involved.

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

Attachment

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: MDAM techniques and Index Skip Scan patch
Next
From: Andres Freund
Date:
Subject: Re: New Object Access Type hooks