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