Re: Documentation update of wal_retrieve_retry_interval to mention table sync worker

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

In response to

Browse pgsql-hackers by date

  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