diff --git a/doc/src/sgml/logical-replication.sgml b/doc/src/sgml/logical-replication.sgml
index 7fdf08b59d0..7b9bb00e5ae 100644
--- a/doc/src/sgml/logical-replication.sgml
+++ b/doc/src/sgml/logical-replication.sgml
@@ -1310,26 +1310,30 @@ test_sub=# SELECT * FROM child ORDER BY a;
    ignoring any column lists.
   </para>
 
-  <sect2 id="logical-replication-col-list-combining">
-   <title>Combining Multiple Column Lists</title>
-
-   <warning>
+   <warning id="logical-replication-col-list-combining">
+    <title>Warning: Combining Column Lists from Multiple Publications</title>
     <para>
-     It is not supported to have a subscription comprising several publications
-     where the same table has been published with different column lists.
-     This means changing the column lists of the tables being subscribed could
-     cause inconsistency of column lists among publications, in which case
-     the <xref linkend="sql-alterpublication"/> will be successful but later
-     the walsender on the publisher, or the subscriber may throw an error. In
-     this scenario, the user needs to recreate the subscription after adjusting
-     the column list or drop the problematic publication using
-     <literal>ALTER SUBSCRIPTION ... DROP PUBLICATION</literal> and then add it
-     back after adjusting the column list.
+     There's currently no support for subscriptions comprising several
+     publications where the same table has been published with different
+     column lists.  <xref linkend="sql-createsubscription"/> disallows
+     creating such subscriptions, but it is still possible to get into
+     that situation by adding or altering column lists on the publication
+     side after a subscription has been created.
+    </para>
+    <para>
+     This means changing the column lists of tables on publications that are
+     already subscribed could lead to errors being thrown on the subscriber
+     side.
+    </para>
+    <para>
+     If a subscription is affected by this problem, the only way to resume
+     replication is to adjust one of the column lists on the publication
+     side so that they all match; and then either recreate the subscription,
+     or use <literal>ALTER SUBSCRIPTION ... DROP PUBLICATION</literal> to
+     remove one of the offending publications and add it again.
     </para>
    </warning>
 
-  </sect2>
-
   <sect2 id="logical-replication-col-list-examples">
    <title>Examples</title>
 
diff --git a/doc/src/sgml/mvcc.sgml b/doc/src/sgml/mvcc.sgml
index 337f6dd4294..b87ad5cc538 100644
--- a/doc/src/sgml/mvcc.sgml
+++ b/doc/src/sgml/mvcc.sgml
@@ -1676,11 +1676,13 @@ SELECT pg_advisory_lock(q.id) FROM
     </para>
 
     <warning>
+     <title>Warning: Serializable Transactions and Data Replication</title>
      <para>
       This level of integrity protection using Serializable transactions
-      does not yet extend to hot standby mode (<xref linkend="hot-standby"/>).
-      Because of that, those using hot standby may want to use Repeatable
-      Read and explicit locking on the primary.
+      does not yet extend to hot standby mode (<xref linkend="hot-standby"/>)
+      or logical replicas.
+      Because of that, those using hot standby or logical replication
+      may want to use Repeatable Read and explicit locking on the primary.
      </para>
     </warning>
    </sect2>
diff --git a/doc/src/sgml/ref/pg_rewind.sgml b/doc/src/sgml/ref/pg_rewind.sgml
index 69d6924b3a2..768024c4911 100644
--- a/doc/src/sgml/ref/pg_rewind.sgml
+++ b/doc/src/sgml/ref/pg_rewind.sgml
@@ -103,6 +103,7 @@ PostgreSQL documentation
   </para>
 
   <warning>
+   <title>Warning: Failures while Rewinding</title>
    <para>
     If <application>pg_rewind</application> fails while processing, then
     the data folder of the target is likely not in a state that can be