Re: Identify missing publications from publisher while create/alter subscription.

On Mon, Jan 25, 2021 at 3:38 PM Bharath Rupireddy
<bharath(dot)rupireddyforpostgres(at)gmail(dot)com> wrote:
>
> On Mon, Jan 25, 2021 at 3:07 PM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
> > > > So basically, the create subscription will throw an error if the
> > > > publication does not exist. So will you throw an error if we try to
> > > > drop the publication which is subscribed by some subscription? I mean
> > > > basically, you are creating a dependency that if you are creating a
> > > > subscription then there must be a publication that is not completely
> > > > insane but then we will have to disallow dropping the publication as
> > > > well. Am I missing something?
> > >
> > > Do you mean DROP PUBLICATION non_existent_publication;?
> > >
> > > Or
> > >
> > > Do you mean when we drop publications from a subscription?
> >
> > I mean it doesn’t seem right to disallow to create the subscription if
> > the publisher doesn't exist, and my reasoning was even though the
> > publisher exists while creating the subscription you might drop it
> > later right?. So basically, now also we can create the same scenario
> > that a subscription may exist for the publication which does not
> > exist.
>
> Yes, the above scenario can be created even now. If a publication is
> dropped in the publisher system, then it will not replicate/publish
> the changes for that publication (publication_invalidation_cb,
> rel_sync_cache_publication_cb, LoadPublications in
> get_rel_sync_entry), so subscriber doesn't receive them. But the
> subscription can still contain that dropped publication in it's list
> of publications.
>
> The patch proposed in this thread, just checks while creation/altering
> of the subscription on the subscriber system whether or not the
> publication exists on the publisher system. This is one way
> dependency. But given the above scenario, there can exist another
> dependency i.e. publisher dropping the publisher at any time. So to
> make it a complete solution i.e. not allowing non-existent
> publications from the list of publications in the subscription, we
> need to detect when the publications are dropped in the publisher and
> we should, may be on a next connection to the subscriber, also look at
> the subscription for that dropped publication, if exists remove it.
> But that's an overkill and impractical I feel. Thoughts?
>
> I also feel the best way to remove the confusion is to document why we
> allow creating subscriptions even when the specified publications
> don't exist on the publisher system? Thoughts?

Yes, that was my point that there is no point in solving it in some
cases and it can exist in other cases. So I am fine with documenting
the behavior.

--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com