Correct timing of portal drop in an execute message

In the extended query protocol, unnamed portals within a transaction
are dropped whenever the next query execution starts, which at that
point creating a new unnamed portal requires dropping the previous one.
This is problematic for problematic for several reasons, not least because
it delays the execution of the ExecutorEnd hook or delays the logging of
temp file usage ( log_temp_files ). This patch addresses the issue by
ensuring that the portal is dropped only after it has been fully
fetched to completion, in the cases that the portal is not a transaction
control statement or requires to be run outside of a transaction block.

Author: Sami Imseih (AWS)

src/backend/tcop/postgres.c

@@ -2321,6 +2321,10 @@ exec_execute_message(const char *portal_name, long max_rows)
 			 * message.  The next protocol message will start a fresh timeout.
 			 */
 			disable_statement_timeout();
+
+			/* unnamed portal executed to completion, so close it */
+			if (portal_name[0] == '\0')
+				PortalDrop(portal, false);
 		}
 
 		/* Send appropriate CommandComplete to client */