RE: Single transaction in the tablesync worker?

> 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.

Best regards,
Houzj