On Thu, Jul 8, 2021 at 3:43 PM Japin Li <japinli@hotmail.com> wrote:
>
> On Thu, 08 Jul 2021 at 17:51, Amit Kapila <amit.kapila16@gmail.com> wrote:
> > On Wed, Jul 7, 2021 at 7:25 PM Japin Li <japinli@hotmail.com> wrote:
> >>
> >> Hi, hackers
> >>
> >> The documentation [1] says:
> >>
> >> When dropping a subscription that is associated with a replication slot on the
> >> remote host (the normal state), DROP SUBSCRIPTION will connect to the remote
> >> host and try to drop the replication slot as part of its operation. This is
> >> necessary so that the resources allocated for the subscription on the remote
> >> host are released. If this fails, either because the remote host is not
> >> reachable or because the remote replication slot cannot be dropped or does not
> >> exist or never existed, the DROP SUBSCRIPTION command will fail. To proceed in
> >> this situation, disassociate the subscription from the replication slot by
> >> executing ALTER SUBSCRIPTION ... SET (slot_name = NONE).
> >>
> >> However, when I try this, it complains the subscription is enabled, this command
> >> requires the subscription disabled. Why we need this limitation?
> >>
> >
> > If we don't have this limitation then even after you have set the slot
> > name to none, the background apply worker corresponding to that
> > subscription will continue to stream changes via the previous slot.
> >
>
> Yeah, thanks for your explain! Should we add some comments here?
>
Sure, but let's keep that as a separate HEAD-only patch.
--
With Regards,
Amit Kapila.
