On Fri, Aug 26, 2022 at 9:33 PM Robert Haas <robertmh...@gmail.com> wrote: > > 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.
I have found one more issue with this approach of rewriting the conflicting table. Earlier I thought we could do the conflict checking and rewriting inside create_new_objects() right before the restore command. But after implementing (while testing) this I realized that we DROP and CREATE the database while restoring the dump that means it will again generate the conflicting system tables. So theoretically the rewriting should go in between the CREATE DATABASE and restoring the object but as of now both create database and restoring other objects are part of a single dump file. I haven't yet analyzed how feasible it is to generate the dump in two parts, first part just to create the database and in second part restore the rest of the object. Thoughts? -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com