v2_doc_update_wal_retrieve_retry_interval_config.patch

diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index fbdd6ce574..b58c7f25f7 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -5094,7 +5094,8 @@ ANY <replaceable class="parameter">num_sync</replaceable> ( <replaceable class="
        </para>
        <para>
         In logical replication, this parameter also limits how often a failing
-        replication apply worker will be respawned.
+        replication apply worker or table synchronization worker will be
+        respawned.
        </para>
       </listitem>
      </varlistentry>
diff --git a/doc/src/sgml/logical-replication.sgml b/doc/src/sgml/logical-replication.sgml
index 8290cd1a08..925e0dd101 100644
--- a/doc/src/sgml/logical-replication.sgml
+++ b/doc/src/sgml/logical-replication.sgml
@@ -1993,18 +1993,17 @@ CONTEXT:  processing remote data for replication origin "pg_16395" during "INSER
     <title>Initial Snapshot</title>
     <para>
      The initial data in existing subscribed tables are snapshotted and
-     copied in a parallel instance of a special kind of apply process.
-     This process will create its own replication slot and copy the existing
-     data.  As soon as the copy is finished the table contents will become
-     visible to other backends.  Once existing data is copied, the worker
-     enters synchronization mode, which ensures that the table is brought
-     up to a synchronized state with the main apply process by streaming
-     any changes that happened during the initial data copy using standard
-     logical replication.  During this synchronization phase, the changes
-     are applied and committed in the same order as they happened on the
-     publisher.  Once synchronization is done, control of the
-     replication of the table is given back to the main apply process where
-     replication continues as normal.
+     copied in a parallel instance of a special kind of table synchronization
+     worker process. This process will create its own replication slot and copy
+     the existing data.  As soon as the copy is finished the table contents will
+     become visible to other backends.  Once existing data is copied, the worker
+     enters synchronization mode, which ensures that the table is brought up to
+     a synchronized state with the main apply process by streaming any changes
+     that happened during the initial data copy using standard logical
+     replication.  During this synchronization phase, the changes are applied
+     and committed in the same order as they happened on the publisher.  Once
+     synchronization is done, control of the replication of the table is given
+     back to the main apply process where replication continues as normal.
     </para>
     <note>
      <para>
@@ -2015,6 +2014,15 @@ CONTEXT:  processing remote data for replication origin "pg_16395" during "INSER
       when copying the existing table data.
      </para>
     </note>
+    <note>
+     <para>
+      If a table synchronization worker fails during copy, the apply worker
+      detects the failure and respawns the table synchronization worker to
+      continue the synchronization process. This behaviour ensures that
+      transient errors do not permanently disrupt the replication setup. See
+      also <link linkend="guc-wal-retrieve-retry-interval"><varname>wal_retrieve_retry_interval</varname></link>.
+     </para>
+    </note>
   </sect2>
  </sect1>