Hi Vignesh,
Here are some review comments for patch v4.
These are cosmetic only; otherwise v4 LGTM.
======
doc/src/sgml/ref/pgupgrade.sgml
1.
Configure the servers for log shipping. (You do not need to run
<function>pg_backup_start()</function> and
<function>pg_backup_stop()</function>
or take a file system backup as the standbys are still synchronized
- with the primary.) Only logical slots on the primary are copied to the
- new standby, but other slots on the old standby are not copied so must
- be recreated manually.
+ with the primary.) If the old cluster is prior to 17.0, then no slots
+ on the primary are copied to the new standby, so all the slots must be
+ recreated manually. If the old cluster is 17.0 or later, then only
+ logical slots on the primary are copied to the new standby, but other
+ slots on the old standby are not copied so must be recreated manually.
</para>
Perhaps the part from "If the old cluster is prior..." should be in a
new paragraph.
======
doc/src/sgml/logical-replication.sgml
2.
+ <para>
+ Setup the <link linkend="logical-replication-config-subscriber">
+ subscriber configurations</link> in the new subscriber.
+ <application>pg_upgrade</application> attempts to migrate subscription
+ dependencies which includes the subscription's table information present in
+ <link linkend="catalog-pg-subscription-rel">pg_subscription_rel</link>
+ system catalog and also the subscription's replication origin. This allows
+ logical replication on the new subscriber to continue from where the
+ old subscriber was up to. Migration of subscription dependencies is only
+ supported when the old cluster is version 17.0 or later. Subscription
+ dependencies on clusters before version 17.0 will silently be ignored.
+ </para>
Perhaps the part from "pg_upgrade attempts..." should be in a new paragraph.
======
Kind Regards,
Peter Smith.
Fujitsu Australia