Hi Vignesh,
Some review comments for your v2 patch.
======
doc/src/sgml/logical-replication.sgml
1.
<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>
AFAICT the only difference you made is changing:
FROM "a special kind of apply process"
TO "a special kind of table synchronization worker process".
There is only ONE kind of tablesync process, so I think saying "a
special kind of table synchronization worker process" seems
misleading. I also thought maybe it is better to mention that this is
PER table.
SUGGESTION:
... a special table synchronization worker process per table.
(e.g. please see attached diff)
======
Kind Regards,
Peter Smith.
Fujitsu Australia
diff --git a/doc/src/sgml/logical-replication.sgml
b/doc/src/sgml/logical-replication.sgml
index 925e0dd..3b01694 100644
--- a/doc/src/sgml/logical-replication.sgml
+++ b/doc/src/sgml/logical-replication.sgml
@@ -1993,8 +1993,8 @@ 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 table synchronization
- worker process. This process will create its own replication slot and copy
+ copied in a parallel instance of a special table synchronization
+ worker process per table. 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
