On Thu, Aug 25, 2022 at 5:26 PM Dilip Kumar <dilipbal...@gmail.com> wrote:
> I agree on this that this system is easy to explain that we just > rewrite anything that conflicts so looks more future-proof. Okay, I > will try this solution and post the patch. 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. 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. Thoughts? -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
