On Thu, Jul 8, 2021 at 3:43 PM Japin Li <japi...@hotmail.com> wrote: > > On Thu, 08 Jul 2021 at 17:51, Amit Kapila <amit.kapil...@gmail.com> wrote: > > On Wed, Jul 7, 2021 at 7:25 PM Japin Li <japi...@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.
