From 4a0e7314f11ee03adfe9df945598c068b4179314 Mon Sep 17 00:00:00 2001 From: Amit Kapila Date: Wed, 22 Jan 2025 10:54:53 +0530 Subject: [PATCH] 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 --- doc/src/sgml/config.sgml | 3 ++- doc/src/sgml/logical-replication.sgml | 35 ++++++++++++++++++--------- 2 files changed, 25 insertions(+), 13 deletions(-) diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml index a8866292d46..a782f109982 100644 --- a/doc/src/sgml/config.sgml +++ b/doc/src/sgml/config.sgml @@ -4953,7 +4953,8 @@ ANY num_sync ( 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. + +