Fix connection leak in DROP SUBSCRIPTION command, take 2.

Commit 898a792eb8 fixed the connection
leak issue, but it was an unreliable way of bugfix. This bugfix was
assuming that walrcv_command() subroutine cannot throw an error,
but it's untenable assumption. For example, if it will be changed
so that an error is thrown, connection leak issue will happen again.

This patch ensures that the connection is closed even when
walrcv_command() subroutine throws an error.

Patch by me, reviewed by Petr Jelinek and Michael Paquier

Discussion: https://www.postgresql.org/message-id/2058.1487704345@sss.pgh.pa.us

src/backend/commands/subscriptioncmds.c

@@ -565,19 +565,25 @@ DropSubscription(DropSubscriptionStmt *stmt, bool isTopLevel)
 						"drop the replication slot \"%s\"", slotname),
 				 errdetail("The error was: %s", err)));
 
-	if (!walrcv_command(wrconn, cmd.data, &err))
+	PG_TRY();
+	{
+		if (!walrcv_command(wrconn, cmd.data, &err))
+			ereport(ERROR,
+					(errmsg("could not drop the replication slot \"%s\" on publisher",
+							slotname),
+					 errdetail("The error was: %s", err)));
+		else
+			ereport(NOTICE,
+					(errmsg("dropped replication slot \"%s\" on publisher",
+							slotname)));
+	}
+	PG_CATCH();
 	{
 		/* Close the connection in case of failure */
 		walrcv_disconnect(wrconn);
-		ereport(ERROR,
-				(errmsg("could not drop the replication slot \"%s\" on publisher",
-						slotname),
-				 errdetail("The error was: %s", err)));
+		PG_RE_THROW();
 	}
-	else
-		ereport(NOTICE,
-				(errmsg("dropped replication slot \"%s\" on publisher",
-						slotname)));
+	PG_END_TRY();
 
 	walrcv_disconnect(wrconn);