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

From Bharath Rupireddy
Subject Re: A proposal to force-drop replication slots to make disabling async/sync standbys or logical replication faster in production environments
Date
Msg-id CALj2ACUYBZS5Bt5Og9JRvJKhm11yV8AMaMt6oV6By_sFeGJFsA@mail.gmail.com
Whole thread Raw
In response to Re: A proposal to force-drop replication slots to make disabling async/sync standbys or logical replication faster in production environments  ("Hsu, John" <hsuchen@amazon.com>)
List pgsql-hackers
On Fri, Jun 10, 2022 at 8:42 PM Hsu, John <hsuchen@amazon.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.



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Logging query parmeters in auto_explain
Next
From: Masahiko Sawada
Date:
Subject: Re: Skipping logical replication transactions on subscriber side