On Thu, 2026-07-09 at 12:47 +0530, Amit Kapila wrote:
> That sounds like an appropriate solution or we can use (connect =
> false) option as well a way to indicate NOCONNECT.
That doesn't have a separate state in the catalog, so DROP SUBSCRIPTION
doesn't know that it was specified.
> 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.".
Right, we can make the documentation match the code instead of making
the code match the documentation. I don't have a strong opinion which
way to go. But the wording above is fine with me.
> 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.
If it can't connnect, then the tablesync slots could still be left
behind, right?
Regards,
Jeff Davis
