On Thu, Jul 9, 2026 at 12:50 AM Jeff Davis <[email protected]> wrote: > > On Wed, 2026-07-08 at 10:29 +0530, Amit Kapila wrote: > > Okay, I see your point and we can make it return early when slot_name > > is NONE. However, do we need to consider a case where users want to > > manually manage the subscription's main slot, so it uses > > slot_name=NONE? I mean users want to manually maintain the lifecycle > > of the slot and due to that even during the CREATE SUBSCRIPTION, it > > uses the specified slot_name instead of the default. But still > > tablesync slots need to be removed in such a case as those are > > internally created. > > The problem is that we are overloading slot_name=NONE, and as you point > out, it can mean multiple things. > > Can we just have DROP SUBSCRIPTION ... FORCE or DROP SUBSCRIPTION ... > NOCONNECT? That allows the user to clearly express their intent at the > time of the drop, rather than guessing from the state of the > subscription. >
That sounds like an appropriate solution or we can use (connect = false) option as well a way to indicate NOCONNECT. > If it's too late to do that for 19, > I feel it is late for 19. we should probably just make the > code match the documentation and don't try to connect if > slot_name=NONE. In most ordinary cases that would not cause a problem, > you'd have to have slot_name=NONE and also drop the subscription before > the table syncs finish. > Yeah, we can do this but if we want to change this behaviour in the next version, isn't it better to tweak the doc wording as:"After that, DROP SUBSCRIPTION will not attempt to drop the subscription's own replication slot. It may still connect to the publisher to drop internally-created table synchronization slots if some table synchronization was left unfinished; if the publisher is unreachable, those slots (and the main slot, if it still exists) must be dropped manually.". I think in most cases where we need this is where the publisher is not available or the network is broken and in those cases, the current code still works and won't leave any tablesync slots. -- With Regards, Amit Kapila.
