On 5/31/17 09:40, Robert Haas wrote: > On Tue, May 30, 2017 at 3:01 PM, Peter Eisentraut > <peter.eisentr...@2ndquadrant.com> wrote: >> On 5/25/17 17:26, Peter Eisentraut wrote: >>> Another way to fix this particular issue is to not verify the >>> replication slot name before doing the drop. After all, if the name is >>> not valid, then you can also just report that it doesn't exist. >> >> Here is a possible patch along these lines. > > I don't see how this solves the problem. Don't you still end up with > an error message telling you that you can't drop the subscription, and > no guidance as to how to fix it?
Well, the idea was to make the error message less cryptic. But I notice that there is really little documentation about this. So how about the attached documentation patch as well? As mentioned earlier, if we want to do HINT messages, that will be a bit more involved and probably PG11 material. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From 3d89b959794abe1bd3addeb9c7c1340187a3cef2 Mon Sep 17 00:00:00 2001 From: Peter Eisentraut <pete...@gmx.net> Date: Wed, 31 May 2017 22:35:33 -0400 Subject: [PATCH] doc: Add note that DROP SUBSCRIPTION drops replication slot Add some information about what to do when this fails. --- doc/src/sgml/ref/drop_subscription.sgml | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/doc/src/sgml/ref/drop_subscription.sgml b/doc/src/sgml/ref/drop_subscription.sgml index 4f34a35eef..42068d617b 100644 --- a/doc/src/sgml/ref/drop_subscription.sgml +++ b/doc/src/sgml/ref/drop_subscription.sgml @@ -74,6 +74,28 @@ <title>Parameters</title> </refsect1> <refsect1> + <title>Notes</title> + + <para> + When dropping a subscription that is associated with a replication slot on + the remote host (the normal state), <command>DROP SUBSCRIPTION</command> + will connect to the remote host and try to drop the replication slot as + part of its operation. This is necessary so that the resources allocated + for the subscription on the remote host are released. If this fails, + either because the remote host is not reachable or because the remote + replication slot cannot be dropped or does not exist or never existed, + the <command>DROP SUBSCRIPTION</command> command will fail. To proceed in + this situation, disassociate the subscription from the replication slot by + executing <literal>ALTER SUBSCRIPTION ... SET (slot_name = NONE)</literal>. + After that, <command>DROP SUBSCRIPTION</command> will no longer attempt any + actions on a remote host. Note that if the remote replication slot still + exists, it should then be dropped manually; otherwise it will continue to + reserve WAL and might eventually cause the disk to fill up. See + also <xref linkend="logical-replication-subscription-slot">. + </para> + </refsect1> + + <refsect1> <title>Examples</title> <para> -- 2.13.0
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
