mirror/postgresql
2
0
Fork 0
mirror of https://git.postgresql.org/git/postgresql.git synced 2025-02-11 19:20:40 +08:00
Code Issues Packages Projects Releases Wiki Activity

Doc: Update the interaction of tablesync with wal_retrieve_retry_interval.

Browse Source 
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
This commit is contained in:
Amit Kapila 2025-01-22 10:54:53 +05:30
parent be31ac2519
commit 4a0e7314f1
2 changed files with 25 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
doc/src/sgml/config.sgml
View File

@ -4953,7 +4953,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>

35
doc/src/sgml/logical-replication.sgml
View File

@ -2017,18 +2017,20 @@ 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 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.
</para>
<note>
<para>
@ -2039,6 +2041,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>