On Wed, Jan 13, 2021 at 1:30 PM Hou, Zhijie <houzj.f...@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.
