From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Josh Berkus <josh(at)agliodbs(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Need Force flag for pg_drop_replication_slot() |
Date: | 2015-05-29 20:41:27 |
Message-ID: | CANP8+jLpQy7Uo8YbSSCywv1MHJhXJBxfym00qOugRcgDrxCQHg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 29 May 2015 at 18:15, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
> pg_drop_replication_slot() can be a time-critical function when the
> master is running out of disk space because the replica is falling
> behind. So I was a little startled by this:
>
> cio=# select
> pg_drop_replication_slot('bdr_24577_6147720645156311471_1_25383__');
> ERROR: replication slot "bdr_24577_6147720645156311471_1_25383__" is
> already active
>
> You have to first terminate the replication connection before you can
> delete the slot ... and do it fast enough that the replica doesn't
> reconnect before you drop the slot.
>
Why would you not stop the receiver first, then drop the slot?
Dropping the slot destroys any chance you have of recovering the downstream
server, so should not be done lightly.
That sounds like a critical fail to me, so making it easier to do that
doesn't sound cool. I oppose this suggestion.
> While I'm just doing this during testing, it could be a critical fail in
> production. I think the simplest way to resolve this would be to add a
> boolean flag to pg_drop_replication_slot(), which would terminate the
> replication connection and delete the slot as a single operation.
>
If you really want it you can write a function to do that for private use.
--
Simon Riggs http://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2015-05-29 20:45:09 | Re: Re: 9.5 release notes may need ON CONFLICT DO NOTHING compatibility notice for FDW authors |
Previous Message | Tom Lane | 2015-05-29 20:37:00 | Re: [CORE] postpone next week's release |