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

From Andres Freund
Subject Re: XMAX_LOCK_ONLY and XMAX_COMMITTED (fk/multixact code)
Date
Msg-id 20220322231347.memqdbrd2m3dgmnj@alap3.anarazel.de
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)
List pgsql-hackers
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@gmail.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



pgsql-hackers by date:

Previous
From: Justin Pryzby
Date:
Subject: Re: New Object Access Type hooks
Next
From: Andres Freund
Date:
Subject: Re: SQL/JSON: functions