On Sat, 25 Nov 2023 at 17:50, Amit Kapila <amit.kapil...@gmail.com> wrote: > > On Sat, Nov 25, 2023 at 7:21 AM vignesh C <vignes...@gmail.com> wrote: > > > > Few comments on v19: > ================== > 1. > + <para> > + The subscriptions will be migrated to the new cluster in a disabled > state. > + After migration, do this: > + </para> > + > + <itemizedlist> > + <listitem> > + <para> > + Enable the subscriptions by executing > + <link linkend="sql-altersubscription"><command>ALTER > SUBSCRIPTION ... ENABLE</command></link>. > > The reason for this restriction is not very clear to me. Is it because > we are using pg_dump for subscription and the existing functionality > is doing it? If so, I think currently even connect is false.
This was done this way so that the apply worker doesn't get started while the upgrade is happening. Now that we have set max_logical_replication_workers to 0, the apply workers will not get started during the upgrade process. I think now we can create the subscriptions with the same options as the old cluster in case of upgrade. > 2. > + * b) SUBREL_STATE_SYNCDONE: A relation upgraded while in this state > + * would retain the replication origin in certain cases. > > I think this is vague. Can we briefly describe cases where the origins > would be retained? I will modify this in the next version > 3. I think the cases where the publisher is also upgraded restoring > the origin's LSN is of no use. Currently, I can't see a problem with > restoring stale originLSN in such cases as we won't be able to > distinguish during the upgrade but I think we should document it in > the comments somewhere in the patch. I will add a comment for this in the next version Regards, Vignesh
