On Mon, 13 Jan 2025 at 12:33, vignesh C wrote:
>
> On Mon, 6 Jan 2025 at 08:47, Peter Smith wrote:
> >
> > Hi Vignesh,
> >
> > Some review comments for your v2 patch.
> >
> > ==
> > doc/src/sgml/logical-replication.sgml
> >
> > AFAICT the only difference you made is changing:
> > FROM "a spec
Patch v3-0001 LGTM
==
Kind Regards,
Peter Smith.
Fujitsu Australia
On Mon, 6 Jan 2025 at 08:47, Peter Smith wrote:
>
> Hi Vignesh,
>
> Some review comments for your v2 patch.
>
> ==
> doc/src/sgml/logical-replication.sgml
>
> AFAICT the only difference you made is changing:
> FROM "a special kind of apply process"
> TO "a special kind of table synchronization
Hi Vignesh,
Some review comments for your v2 patch.
==
doc/src/sgml/logical-replication.sgml
1.
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 replic
On Tue, 31 Dec 2024 at 02:48, Peter Smith wrote:
>
> On Thu, Dec 26, 2024 at 1:37 AM vignesh C wrote:
> >
> > Hi,
> >
> > Currently, we restart the table synchronization worker after the
> > duration specified by wal_retrieve_retry_interval following the last
> > failure. While this behavior is d
On Thu, Dec 26, 2024 at 1:37 AM vignesh C wrote:
>
> Hi,
>
> Currently, we restart the table synchronization worker after the
> duration specified by wal_retrieve_retry_interval following the last
> failure. While this behavior is documented for apply workers, it is
> not mentioned for table synch
Hi,
Currently, we restart the table synchronization worker after the
duration specified by wal_retrieve_retry_interval following the last
failure. While this behavior is documented for apply workers, it is
not mentioned for table synchronization workers. I believe this detail
should be included in
