Hi,
Why couldn't you terminate the active_pid associated with the slot you
want to drop if it's active prior to dropping?
On 6/10/22 3:03 AM, Bharath Rupireddy wrote:
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you
canconfirm the sender and know the content is safe.
>
>
>
> On Thu, Jun 9, 2022 at 12:11 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>> On Thu, Jun 9, 2022 at 11:07 AM Bharath Rupireddy
>> <bharath.rupireddyforpostgres@gmail.com> wrote:
>>> Currently postgres doesn't allow dropping a replication slot that's active [1]. This can make certain operations
moretime-consuming or stuck in production environments. These operations are - disable async/sync standbys and disable
logicalreplication that require the postgres running on standby or the subscriber to go down. If stopping postgres
servertakes time, the VM or container will have to be killed forcefully which can take a considerable amount of time as
thereare many layers in between.
>>>
>> Why do you want to drop the slot when the server is going down? Is it
>> some temporary replication slot, otherwise, how will you resume
>> replication after restarting the server?
> The setup is this - primary, bunch of sync standbys, bunch of read
> replicas (async standbys), bunch of logical replication subscribers -
> now, the user wants to remove any of them for whatever reasons,
> typical flow is to first stop the server, if stopping the server takes
> time (for instance the standbys or subscribers lag behind the primary
> by too much), kill the VM/host server to make the corresponding
> replication slots inactive on the primary and then drop the
> replication slots. The proposed force-drop function helps speed up
> these operations in production environments and it will also be
> possible to provide an SLA for these disable operations.
>
> I hope the user case is clear.
>
> Regards,
> Bharath Rupireddy.
>
>