On Wed, Jan 21, 2026 at 08:59:51AM -0800, Mark Dilger wrote: > On Wed, Oct 23, 2024 at 7:54 PM Noah Misch <[email protected]> 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.
