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 <[email protected]> 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?
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.
