From: | Peter Smith <smithpb2250(at)gmail(dot)com> |
---|---|
To: | vignesh C <vignesh21(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Documentation update of wal_retrieve_retry_interval to mention table sync worker |
Date: | 2025-01-06 03:17:14 |
Message-ID: | CAHut+PsiMLTxOnHLFYbccjL=RY1Ke7xRZOcNLQX51Sv4nUG3qA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
Attachment | Content-Type | Size |
---|---|---|
PS_NITPICKS_V2.txt | text/plain | 1001 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | Japin Li | 2025-01-06 03:32:21 | Re: RFC: Lock-free XLog Reservation from WAL |
Previous Message | Amit Kapila | 2025-01-06 03:15:09 | Re: Conflict detection for update_deleted in logical replication |