On Mon, Jan 11, 2021 at 3:53 PM Ajin Cherian <itsajin@gmail.com> wrote:
>
> On Thu, Jan 7, 2021 at 3:20 PM Amit Kapila <amit.kapila16@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.
