On Mon, Jan 11, 2021 at 3:53 PM Ajin Cherian <itsa...@gmail.com> wrote: > > On Thu, Jan 7, 2021 at 3:20 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > > > BTW, I have analyzed whether we need any modifications to > > > pg_dump/restore for this patch as this changes the state of one of the > > > fields in the system table and concluded that we don't need any > > > change. For subscriptions, we don't dump any of the information from > > > pg_subscription_rel, rather we just dump subscriptions with the > > > connect option as false which means users need to enable the > > > subscription and refresh publication after restore. I have checked > > > this in the code and tested it as well. The related information is > > > present in pg_dump doc page [1], see from "When dumping logical > > > replication subscriptions ....". > > > > > > > I have further analyzed that we don't need to do anything w.r.t > > pg_upgrade as well because it uses pg_dump/pg_dumpall to dump the > > schema info of the old cluster and then restore it to the new cluster. > > And, we know that pg_dump ignores the info in pg_subscription_rel, so > > we don't need to change anything as our changes are specific to the > > state of one of the columns in pg_subscription_rel. I have not tested > > this but we should test it by having some relations in not_ready state > > and then allow the old cluster (<=PG13) to be upgraded to new (pg14) > > both with and without this patch and see if there is any change in > > behavior. > > I have tested this scenario, stopped a server running PG_13 when > subscription table sync was in progress. >
Thanks for the test. This confirms my analysis and we don't need any change in pg_dump or pg_upgrade for this patch. -- With Regards, Amit Kapila.
