On Tue, Jan 12, 2021 at 4:59 PM Bharath Rupireddy
<bharath.rupireddyforpostgres@gmail.com> wrote:
>
> On Tue, Jan 12, 2021 at 12:06 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> > > Here's my analysis:
> > > 1) in the publisher, alter publication drop table successfully
> > > removes(PublicationDropTables) the table from the catalogue
> > > pg_publication_rel
> > > 2) in the subscriber, alter subscription refresh publication
> > > successfully removes the table from the catalogue pg_subscription_rel
> > > (AlterSubscription_refresh->RemoveSubscriptionRel)
> > > so far so good
> > >
> >
> > Here, it should register the worker to stop on commit, and then on
> > commit it should call AtEOXact_ApplyLauncher to stop the apply worker.
> > Once the apply worker is stopped, the corresponding WALSender will
> > also be stopped. Something here is not happening as per expected
> > behavior.
>
> On the subscriber, an entry for worker stop is created in AlterSubscription_refresh -->
logicalrep_worker_stop_at_commit.At the end of txn, in AtEOXact_ApplyLauncher, we try to stop that worker, but it
cannotbe stopped because logicalrep_worker_find returns null (AtEOXact_ApplyLauncher --> logicalrep_worker_stop -->
logicalrep_worker_find).The worker entry for that subscriber is having relid as 0 [1], due to which the following if
conditionwill not be hit. The apply worker on the subscriber related to the subscription on which refresh publication
wasrun is not closed. It looks like relid 0 is valid because it will be applicable only during the table sync phase,
thecomment in the LogicalRepWorker structure says that.
>
> And also, I think, expecting the apply worker to be closed this way doesn't make sense because the apply worker is a
per-subscriptionbase, and the subscription can have other tables too.
>
Okay, that makes sense. As responded to Li Japin, let's focus on
figuring out why we are sending the changes from the publisher node in
some cases and not in other cases.
--
With Regards,
Amit Kapila.
