database/postgres
database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-06-05 23:56:58 +03:00
Code

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>
<para> <para>
In logical replication, this parameter also limits how often a failing 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> </para>
</listitem> </listitem>
</varlistentry> </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> <title>Initial Snapshot</title>
<para> <para>
The initial data in existing subscribed tables are snapshotted and The initial data in existing subscribed tables are snapshotted and
copied in a parallel instance of a special kind of apply process. copied in a parallel instances of a special kind of apply process.
This process will create its own replication slot and copy the existing These special apply processes are dedicated table synchronization
data. As soon as the copy is finished the table contents will become workers, spawned for each table to be synchronized. Each table
visible to other backends. Once existing data is copied, the worker synchronization process will create its own replication slot and
enters synchronization mode, which ensures that the table is brought copy the existing data. As soon as the copy is finished the table
up to a synchronized state with the main apply process by streaming contents will become visible to other backends. Once existing data
any changes that happened during the initial data copy using standard is copied, the worker enters synchronization mode, which ensures
logical replication. During this synchronization phase, the changes that the table is brought up to a synchronized state with the main
are applied and committed in the same order as they happened on the apply process by streaming any changes that happened during the
publisher. Once synchronization is done, control of the initial data copy using standard logical replication. During this
replication of the table is given back to the main apply process where synchronization phase, the changes are applied and committed in the same
replication continues as normal. 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> </para>
<note> <note>
<para> <para>
@ -2039,6 +2041,15 @@ CONTEXT: processing remote data for replication origin "pg_16395" during "INSER
when copying the existing table data. when copying the existing table data.
</para> </para>
</note> </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> </sect2>
</sect1> </sect1>