On Fri, Aug 26, 2022 at 7:01 AM Dilip Kumar <dilipbal...@gmail.com> wrote: > While working on this solution I noticed one issue. Basically, the > problem is that during binary upgrade when we try to rewrite a heap we > would expect that “binary_upgrade_next_heap_pg_class_oid” and > “binary_upgrade_next_heap_pg_class_relfilenumber” are already set for > creating a new heap. But we are not preserving anything so we don't > have those values. One option to this problem is that we can first > start the postmaster in non-binary upgrade mode perform all conflict > checking and rewrite and stop the postmaster. Then start postmaster > again and perform the restore as we are doing now. Although we will > have to start/stop the postmaster one extra time we have a solution.
Yeah, that seems OK. Or we could add a new function, like binary_upgrade_allow_relation_oid_and_relfilenode_assignment(bool). Not sure which way is better. > But while thinking about this I started to think that since now we are > completely decoupling the concept of Oid and relfilenumber then > logically during REWRITE we should only be allocating new > relfilenumber but we don’t really need to allocate the Oid at all. > Yeah, we can do that if inside make_new_heap() if we pass the > OIDOldHeap to heap_create_with_catalog(), then it will just create new > storage(relfilenumber) but not a new Oid. But the problem is that the > ATRewriteTable() and finish_heap_swap() functions are completely based > on the relation cache. So now if we only create a new relfilenumber > but not a new Oid then we will have to change this infrastructure to > copy at smgr level. I think it would be a good idea to continue preserving the OIDs. If nothing else, it makes debugging way easier, but also, there might be user-defined regclass columns or something. Note the comments in check_for_reg_data_type_usage(). -- Robert Haas EDB: http://www.enterprisedb.com