Re: A proposal to force-drop replication slots to make disabling async/sync standbys or logical replication faster in production environments

On Fri, Jun 10, 2022 at 8:42 PM Hsu, John <hsuchen(at)amazon(dot)com> wrote:
>
> Hi,
>
> Why couldn't you terminate the active_pid associated with the slot you
> want to drop if it's active prior to dropping?

In that case, the slot becomes active immediately after killing the
old walsender because the standby/subscriber opens another connection
with the primary using the same replication slot. The replication slot
will be inactive for a moment during pg_terminate_backend and becomes
active again by the time we call pg_drop_replication_slot and we hit
the same ERROR: replication slot "foo" is active for PID XXXXX.

The idea proposed here is to have a force-drop function that
terminates the walsender gracefully and drops the replication slot
even though there's somebody using it and all of this is done with an
exclusive lock on the slot so that nobody can acquire it while we are
dropping it.

Regards,
Bharath Rupireddy.