Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lm0cm-0005aE-QV for pgsql-hackers@arkaria.postgresql.org; Wed, 26 May 2021 20:59:33 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lm0ck-0007JT-PQ for pgsql-hackers@arkaria.postgresql.org; Wed, 26 May 2021 20:59:30 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lm0cj-0007JJ-W7 for pgsql-hackers@lists.postgresql.org; Wed, 26 May 2021 20:59:30 +0000 Received: from wout2-smtp.messagingengine.com ([64.147.123.25]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lm0cd-00030f-Ko for pgsql-hackers@lists.postgresql.org; Wed, 26 May 2021 20:59:28 +0000 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 6B9991485; Wed, 26 May 2021 16:59:21 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Wed, 26 May 2021 16:59:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:subject:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; bh=WA4xQk8uBpBnbidd6dDZxvO4k1lbqoVWYrdzQKcYWQg=; b=R3xdb4Va 4PonX99diwr1fhnLwAaPrTCI6oA4uy7NABjFX25L0MAbbD1b78w4jA8mD6G6bgWc rscl5pNWUGOThmfK8RVdgZaVJbqXdA7gdbU0sn6BPbTwMLv6qdC1+YG5wT0jnVJW /EyfapOhLL3E+SPujX8H3rOl1mnzpF9ZfHPEt0IH6ld/5cxxIA1LWylaU7QBT1UO PNcude7Dx9e1fWsY1Eg20lvi6THuh/RDvBSf9jJaiy0DZDzCZTtBfHInquKD09JF Kbwwz3pKQB9GHFbs8DqlsjW/dVC4d81d4vTTz+JS+0a76I9LgAqHURZkP42rO58N zS2LrgWdbdrP0w== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdekfedgudehjecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpeffhffvuffkgggtugfgjgesthekredttddtjeenucfhrhhomheptehlvhgr rhhoucfjvghrrhgvrhgruceorghlvhhhvghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrgh eqnecuggftrfgrthhtvghrnhepledvgfffvedvieeukeekjedvtdefteeuieejtedtgfeh leefieefueetleduveeunecukfhppeduledtrdelhedrudelrdelheenucevlhhushhtvg hrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrlhhvhhgvrhhrvgesrghl vhhhrdhnohdqihhprdhorhhg X-ME-Proxy: Received: from perhan.alvh.no-ip.org (unknown [190.95.19.95]) by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 26 May 2021 16:59:19 -0400 (EDT) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id 1D29B2A0A8B; Wed, 26 May 2021 16:59:17 -0400 (-04) Date: Wed, 26 May 2021 16:59:17 -0400 From: Alvaro Herrera To: Yura Sokolov Cc: Tom Lane , pgsql-hackers@lists.postgresql.org Subject: Re: Add PortalDrop in exec_execute_message Message-ID: <202105262059.dnf27qpnccuv@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 2021-May-25, Yura Sokolov wrote: > Tom Lane писал 2021-05-21 21:23: > > Yura Sokolov writes: > > > I propose to add PortalDrop at the 'if (completed)' branch of > > > exec_execute_message. > > > > This violates our wire protocol specification, which > > specifically says > > > > If successfully created, a named portal object lasts till the end of > > the current transaction, unless explicitly destroyed. An unnamed > > portal is destroyed at the end of the transaction, or as soon as the > > next Bind statement specifying the unnamed portal as destination is > > issued. (Note that a simple Query message also destroys the unnamed > > portal.) > > > > I'm inclined to think that your complaint would be better handled > > by having the client send a portal-close command, if it's not > > going to do something else immediately. > > I thought about it as well. Then, if I understand correctly, > PQsendQueryGuts and PQsendQueryInternal in pipeline mode should send > "close portal" (CP) message after "execute" message, right? I don't think they should do that. The portal remains open, and the libpq interface does that. The portal gets closed at end of transaction without the need for any client message. I think if the client wanted to close the portal ahead of time, it would need a new libpq entry point to send the message to do that. (I didn't add a Close Portal message to PQsendQueryInternal in pipeline mode precisely because there is no such message in PQsendQueryGuts. I think it would be wrong to unconditionally add a Close Portal message to any of those places.) -- Álvaro Herrera 39°49'30"S 73°17'W