Re: Documentation to upgrade logical replication cluster

Here are some review comments for patch v3.

======
doc/src/sgml/ref/pgupgrade.sgml

1.
+
+ <para>
+ This page does not cover steps to upgrade logical replication
clusters, refer
+ <xref linkend="logical-replication-upgrade"/> for details on upgrading
+ logical replication clusters.
+ </para>
+

I felt that maybe this note was misplaced. Won't it be better to put
this down in the "Usage" section of this page?

BEFORE
These are the steps to perform an upgrade with pg_upgrade:

SUGGESTION (or something like this)
Below are the steps to perform an upgrade with pg_upgrade.

Note, the steps to upgrade logical replication clusters are not
covered here; refer to <xref linkend="logical-replication-upgrade"/>
for details.

~~~

2.
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.) In version 17.0 or later, 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>

This para was still unclear to me. What is version 17.0 referring to
-- the old_cluster version? Do you mean something like:
If the old cluster is < v17 then logical slots are not copied. If the
old_cluster is >= v17 then...

======
doc/src/sgml/logical-replication.sgml

3.
+ <para>
+ While upgrading a subscriber, write operations can be performed in the
+ publisher, these changes will be replicated to the subscriber once the
+ subscriber upgradation is completed.
+ </para>

3a.
/publisher, these changes/publisher. These changes/

~

3b.
"upgradation" ??. See [1]

maybe just /upgradation/upgrade/

~~~

4. GENERAL - prompts/paths

I noticed in v3 you removed all the cmd prompts like:
dba(at)node1:/opt/PostgreSQL/postgres/17/bin$
dba(at)node2:/opt/PostgreSQL/postgres/18/bin$
etc.

I thought those were helpful to disambiguate which server/version was
being operated on. I wonder if there is some way to keep information
still but not make it look like a real current directory that
Kuroda-san did not like:

e.g. Maybe something like the below is possible?

(dba(at)node1: v17) pg_upgrade...
(dba(at)node2: v18) pg_upgrade...

======
[1] https://english.stackexchange.com/questions/192187/upgradation-not-universally-accepted#:~:text=Not%20all%20dictionaries%20(or%20native,by%20most%20non%2DIE%20speakers.

Kind Regards,
Peter Smith.
Fujitsu Australia