From: Noah Misch <noah@leadboat.com>
To: Mark Dilger <mark.dilger@enterprisedb.com>
Cc: Nitin Motiani <nitinmotiani@google.com>
Cc: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@postgresql.org
Subject: Re: Inval reliability, especially for inplace updates
Date: Wed, 21 Jan 2026 09:47:20 -0800
Message-ID: <20260121174720.71.noahmisch@microsoft.com> (raw)
In-Reply-To: <CAHgHdKsQYHz4XDOtUwNSn+JRv1kyatLiNYLHu4Y9V_xR4Y5kpA@mail.gmail.com>
References: <20240618015730.jijhox2a3w3t26en@awork3.anarazel.de>
<20240618152349.7f.nmisch@google.com>
<20240831010711.67.nmisch@google.com>
<20240930193350.04.nmisch@google.com>
<CAH5HC9508Xvz4BVca8OCoDOv7pgHqAf85EqZkWMZ_Q2hAkebzg@mail.gmail.com>
<20241013004511.9c.nmisch@google.com>
<CAH5HC94r2ZKy_MhNaPUjn7NHkOFgbyBAgV2jaYSRt35BNWuOAA@mail.gmail.com>
<CAH5HC95rn4gON8zNrFXFY-Cn4z0NZuDU_1TDwKnafX_25_C0UA@mail.gmail.com>
<20241024025357.a8.nmisch@google.com>
<CAHgHdKsQYHz4XDOtUwNSn+JRv1kyatLiNYLHu4Y9V_xR4Y5kpA@mail.gmail.com>
On Wed, Jan 21, 2026 at 08:59:51AM -0800, Mark Dilger wrote:
> On Wed, Oct 23, 2024 at 7:54 PM Noah Misch <noah@leadboat.com> wrote:
> > I'm attaching the branch-specific patches for that and for the main fix.
> > Other notes from back-patching:
> >
> > - All branches change the ABI of PrepareToInvalidateCacheTuple(), a
> > function
> > catcache.c exports for the benefit of inval.c. No PGXN extension calls
> > that, and I can't think of a use case in extensions.
>
> Unfortunately, I can think of four.
Those are non-PGXN extensions, right?
Based on your experience, I probably should encourage packagers to do an early
check of the packages they build, especially if they build tableam modules not
found in PGXN. How do you see it?
> I have four Table Access Methods that
> I now need to fork to be compatible with 18.0 and 18.1 on the one hand, and
> 18.2 onward on the other.
For what it's worth, the ABI break you quoted is the v14-v17 break, not the
v18 break:
- v18.2 (06b030e) is changing the CacheInvalidateHeapTupleInplace() ABI
- v14-v17 (e.g. 2e58802) is changing the PrepareToInvalidateCacheTuple() ABI
> I'm sorry I didn't follow this thread before it got pushed.
>
> Is there a reason for doing this change in back branches? The thread is
> pretty long, and I'm struggling to find a security or stability
> justification for the ABI break, but perhaps there is one.
Chiefly, the fix prevents data loss that arose via losing a relhasindex,
relfrozenxid, or datfrozenxid update. (The log message of 0f69bed says
"another backend's DDL could then update the row without incorporating the
inplace update".) For an example, see where that commit edits
src/test/isolation/expected/inplace-inval.out.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: noah@leadboat.com, mark.dilger@enterprisedb.com, nitinmotiani@google.com, andres@anarazel.de
Subject: Re: Inval reliability, especially for inplace updates
In-Reply-To: <20260121174720.71.noahmisch@microsoft.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox