> 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
