On Tue, 12 Jan 2021 at 13:39, Amit Kapila wrote: > On Tue, Jan 12, 2021 at 9:58 AM japin <japi...@hotmail.com> wrote: >> >> >> 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. >> > > Hmm, but in Bharath's test, it is replicating the Inserts in step-7 > and step-9 as well. Are you seeing something different? >
Yes, however if we don't Inserts in step-5, the Inserts in step-7 and step-9 will not replicate. -- Regrads, Japin Li. ChengDu WenWu Information Technology Co.,Ltd.
