On Wed, Jan 13, 2021 at 1:30 PM Hou, Zhijie <houzj.fnst@cn.fujitsu.com> wrote:
>
> > I am not exactly sure of the concern. (If the extra info below does not
> > help can you please describe your concern with more details).
> >
> > This [v14] patch code/feature is only referring to the immediate stopping
> > of only the *** "tablesync" *** worker (if any) for any/each table being
> > removed from the subscription. It has nothing to say about the "apply" worker
> > of the subscription, which continues replicating as before.
> >
> > OTOH, I think the other mail problem is not really related to the "tablesync"
> > workers. As you can see (e.g. steps 7,8,9,10 of [2]), that problem is
> > described as continuing over multiple transactions to replicate unexpected
> > rows - I think this could only be done by the subscription "apply" worker,
> > and is after the "tablesync" worker has gone away.
> >
> > So AFAIK these are 2 quite unrelated problems, and would be solved
> > independently.
> >
> > It just happens that they are both exposed using ALTER SUBSCRIPTION ...
> > REFRESH PUBLICATION;
>
> So sorry for the confusion, you are right that these are 2 quite unrelated problems.
> I misunderstood the 'stop the worker' here.
>
>
> + /* Immediately stop the worker. */
> + logicalrep_worker_stop_at_commit(subid, relid); /* prevent re-launching */
> + logicalrep_worker_stop(subid, relid); /* stop immediately */
>
> Do you think we can add some comments to describe what type "worker" is stop here ? (sync worker here)
> And should we add some more comments to talk about the reason of " Immediately stop " here ? it may looks easier to
understand.
>
Another thing related to this is why we need to call both
logicalrep_worker_stop_at_commit() and logicalrep_worker_stop()?
--
With Regards,
Amit Kapila.
