Re: Refactor how we form HeapTuples for CatalogTuple(Insert|Update)

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Greg Burd <greg(at)burd(dot)me>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, John Naylor <johncnaylorls(at)gmail(dot)com>
Subject: Re: Refactor how we form HeapTuples for CatalogTuple(Insert|Update)
Date: 2025-12-04 05:50:09
Message-ID: aTEhEQ8hbJHV9cJ8@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Dec 03, 2025 at 09:11:03AM -0500, Greg Burd wrote:
> On Dec 2 2025, at 11:16 pm, Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> I've looked in the email archives a bit and didn't come up with much
> related to catalog upgrades. I don't know if there is much on the
> record information on this idea, but from what I've been told the idea
> of decoupling heap from catalogs with the goal of getting closer to
> making online upgrades possible has been referenced a few times in
> hallway tracks at various conferences.

John Naylor has been looking at this problem at some point, if I
recall correctly. Adding him in CC here for comments and opinions, or
perhaps I am just wrong in assuming that he has looked at this area.

> I'll see what I can do to extract this piece into a separate patch.

Thanks. I suspect that it would help with the clarity of the changes.
At least I am getting the same impression after reading v2, which is
close enough to v1 except for the various renames.

> There are two major paths into heap_update(), one from
> heapam_tuple_update() and one from simple_heap_update(). The first is
> from the executor side via the table AM API and my other thread [6] that
> you referenced is trying to address that. This thread is focused on the
> catalog updates that flow into simple_heap_update(). Really that
> function should be renamed to catalog_heap_update() as that's the only
> purpose AFAICT.

You have a point based on how things are presented in this patch set,
where there is only one caller of simple_heap_update(), versus two on
HEAD.

> Does that connect the dots a bit more clearly?
>
> * 0003 Refactor how we form HeapTuples for CatalogTuple(Insert|Update)
>
> This commit is borrowed from the other thread to demonstrate how these
> changes impact heap updates. Thanks for your consideration, I
> appreciate your time.

Now I see the connection, thanks to 0003 where simple_heap_update()
gains its Bitmapset that tracks the set of updated tuples, for the
business that happens in CatalogTupleUpdate(). All that is going to
need a careful lookup.
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Langote 2025-12-04 05:54:09 Re: index prefetching
Previous Message Tom Lane 2025-12-04 05:32:47 Re: Something in our JIT code is screwing up PG_PRINTF_ATTRIBUTE