Horton
Menu

Re: Inval reliability, especially for inplace updates

Noah Misch <noah@leadboat.com>

View thread
From: Noah Misch <noah@leadboat.com>
To: Peter Eisentraut <peter@eisentraut.org>
Cc: Mark Dilger <mark.dilger@enterprisedb.com>, Nitin Motiani <nitinmotiani@google.com>, Andres Freund <andres@anarazel.de>, pgsql-hackers@postgresql.org
Date: 2026-02-17T00:22:39Z
Lists: pgsql-hackers 
On Mon, Feb 16, 2026 at 08:52:42PM +0100, Peter Eisentraut wrote:
> On 22.01.26 18:42, Noah Misch wrote:
> > On Thu, Jan 22, 2026 at 07:53:21AM -0800, Mark Dilger wrote:
> > > On Wed, Jan 21, 2026 at 9:47 AM Noah Misch <noah@leadboat.com> wrote:
> > > > 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 don't know what you mean by "early".  18.2 hasn't stamped yet.  18.1
> > > doesn't have the change.  So, I'd say that I'm building pretty early, and I
> > > noticed the change will be coming in 18.2.
> > 
> > I'll probably say:
> > 
> >    If you've tested your packaging builds against REL_17_STABLE and
> >    REL_18_STABLE since 2025-12-16 *or* you package only modules present in
> >    PGXN, you can stop reading.
> > 
> >    Mark Dilger reported non-PGXN tableam modules that needed changes to cope
> >    with back-patched signature changes in functions
> >    CacheInvalidateHeapTupleInplace() (commit 06b030e) and
> >    PrepareToInvalidateCacheTuple() (commit 2e58802).  Consider trying a rebuild
> >    against REL_17_STABLE and REL_18_STABLE now, so you learn about any similar
> >    need for changes in your modules.
> 
> It has been requested to revert these, because they are an ABI and API
> break, and they are unnecessary in the backbranches.  Could we do this
> please?

The old API version was in 18.0 and 18.1 only.  The new one is in 18.2, 17.8,
16.12, 15.16, and 14.21.  How does your risk calculation weigh that?  Let's
talk about what you and others are seeing, in much more detail.

> > > Oh, I don't mean to question the overall purpose of the patch.  I was
> > > questioning whether it needed to have breaking changes which are mere "code
> > > cleanup".  The change to CacheInvalidateHeapTupleInplace to remove the
> > > unused third argument seemed inappropriate for backpatching, so I spoke up
> > > before 18.2 is stamped.  Doing this one piece of code cleanup in the back
> > > branches will cause a lot of packaging pain for no real benefit.
> > 
> > Is the source code for one of these modules published?  I'm not picturing how
> > a module could need a CacheInvalidateHeapTupleInplace() call, so your code may
> > illuminate that for me.
> > 
> > If you upload one of these modules to PGXN, my scans before future ABI breaks
> > will find its calls and will block avoidable ABI breaks like the
> > CacheInvalidateHeapTupleInplace() one.
> 
> Since the heap AM calls this, it doesn't seem surprising that another table
> AM would call it too.

That is not the case.  Inplace updates are not part of the table AM API.
Since the system catalogs use heap, heap offers inplace updates.  Where code
performs heap inplace updates, heap function names appear verbatim.

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Update .abi-compliance-history for PrepareToInvalidateCacheTuple().

  2. Assert lack of hazardous buffer locks before possible catalog read.

  3. For inplace update, send nontransactional invalidations.

  4. Update .abi-compliance-history for CacheInvalidateHeapTupleInplace().

  5. Revisit cosmetics of "For inplace update, send nontransactional invalidations."

  6. Correct comments of "Fix data loss at inplace update after heap_update()".

  7. Move I/O before the index_update_stats() buffer lock region.

  8. Revert "For inplace update, send nontransactional invalidations."

  9. Revert "WAL-log inplace update before revealing it to other sessions."

  10. Fix inplace update buffer self-deadlock.

  11. Remove duplicate words in comments

  12. At end of recovery, reset all sinval-managed caches.

  13. Fix data loss at inplace update after heap_update().

  14. Remove comment about xl_heap_inplace "AT END OF STRUCT".

  15. Reduce memory consumption for pending invalidation messages.

  16. Add support for streaming to built-in logical replication.

  17. WAL Log invalidations at command end with wal_level=logical.

  18. Introduce logical decoding.

  19. Rename and document some invalidation routines to make it clearer that