From: | vignesh C <vignesh21(at)gmail(dot)com> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Peter Smith <smithpb2250(at)gmail(dot)com>, "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, Julien Rouhaud <rjuju123(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: pg_upgrade and logical replication |
Date: | 2023-11-27 09:48:16 |
Message-ID: | CALDaNm1-1Ong61cPmCOXMzDjhnRurtszwuss_gV0XrWjX8nG8A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, 25 Nov 2023 at 17:50, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Sat, Nov 25, 2023 at 7:21 AM vignesh C <vignesh21(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Langote | 2023-11-27 10:09:34 | Re: remaining sql/json patches |
Previous Message | Dominique Devienne | 2023-11-27 09:44:55 | Re: Emitting JSON to file using COPY TO |