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.
