Re: XMAX_LOCK_ONLY and XMAX_COMMITTED (fk/multixact code)

Hi,

On 2022-03-22 16:06:40 -0700, Nathan Bossart wrote:
> 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.

> From 2d6b372cf61782e0fd52590b57b1c914b0ed7a4c Mon Sep 17 00:00:00 2001
> From: Nathan Bossart <nathandbossart(at)gmail(dot)com>
> Date: Tue, 22 Mar 2022 15:35:34 -0700
> Subject: [PATCH v4 1/1] disallow XMAX_COMMITTED + XMAX_LOCK_ONLY

Just skimming this thread quickly, I really have no idea what this is trying
to achieve and the commit message doesn't help either... I didn't read the
referenced thread, but I shouldn't have to, to get a basic idea.

Greetings,

Andres Freund