On Tue, 12 Jan 2021 at 11:37, Amit Kapila wrote: > On Mon, Jan 11, 2021 at 6:51 PM Bharath Rupireddy > <bharath.rupireddyforpostg...@gmail.com> wrote: >> >> Hi, >> >> While providing thoughts on the design in [1], I found a strange >> behaviour with the $subject. The use case is shown below as a sequence >> of steps that need to be run on publisher and subscriber to arrive at >> the strange behaviour. In step 5, the table is dropped from the >> publication and in step 6, the refresh publication is run on the >> subscriber, from here onwards, the expectation is that no further >> inserts into the publisher table have to be replicated on to the >> subscriber, but the opposite happens i.e. the inserts are still >> replicated to the subscriber. ISTM as a bug. Let me know if I'm >> missing anything. >> > > Did you try to investigate what's going on? Can you please check what > is the behavior if, after step-5, you restart the subscriber and > separately try creating a new subscription (maybe on a different > server) for that publication after step-5 and see if that allows the > relation to be replicated? AFAIU, in AlterSubscription_refresh, we > remove such dropped rels and stop their corresponding apply workers > which should stop the further replication of such relations but that > doesn't seem to be happening in your case.
If we restart the subscriber after step-5, it will not replicate the records. As I said in [1], if we don't insert a new data in step-5, it will not replicate the records. In both cases, the AlterSubscription_refresh() call RemoveSubscriptionRel() and logicalrep_worker_stop_at_commit(). However, if we insert a data in step-5, it doesn't work as expected. Any thoughts? [1] https://www.postgresql.org/message-id/a7a618fb-f87c-439c-90a3-93cf9e734...@hotmail.com -- Regrads, Japin Li. ChengDu WenWu Information Technology Co.,Ltd.
