Doc: Update the interaction of tablesync with wal_retrieve_retry_interval.

In passing, update the documentation that explains the process of initial
data replication to explicitly state that it uses a table synchronization
worker.

Author: Vignesh C
Reviewed-by: Peter Smith, Shlok Kyal, Amit Kapila
Discussion: https://postgr.es/m/CALDaNm3RxGcD4cDAV5Q0_A4n06F3+AAMpxiyND9Zn0dB86hFmg@mail.gmail.com

diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index a8866292d46052e4e5227c3fe42b9e9abb7b2d7d..a782f109982433556388d554a6a180a603f15902 100644 (file)
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -4953,7 +4953,8 @@ ANY num_sync ( 
        
        
         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.
        
       
      

diff --git a/doc/src/sgml/logical-replication.sgml b/doc/src/sgml/logical-replication.sgml
index 7cc5f4b18d66199ad060d90c2a76da5ff6fcaebb..ab683cf111edf84ac537efbfe5808e1b28f7ded8 100644 (file)
--- a/doc/src/sgml/logical-replication.sgml
+++ b/doc/src/sgml/logical-replication.sgml
@@ -2017,18 +2017,20 @@ CONTEXT:  processing remote data for replication origin "pg_16395" during "INSER
     Initial Snapshot
     
      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 instances of a special kind of apply process.
+     These special apply processes are dedicated table synchronization
+     workers, spawned for each table to be synchronized.  Each table
+     synchronization 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.
     
     
      
@@ -2039,6 +2041,15 @@ CONTEXT:  processing remote data for replication origin "pg_16395" during "INSER
       when copying the existing table data.
      
     
+    
+     
+      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 wal_retrieve_retry_interval.
+     
+