On Wed, Dec 03, 2025 at 09:11:03AM -0500, Greg Burd wrote: > On Dec 2 2025, at 11:16 pm, Michael Paquier <[email protected]> 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
signature.asc
Description: PGP signature
