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 1nHRzF-00038Y-UU for pgsql-hackers@arkaria.postgresql.org; Tue, 08 Feb 2022 15:00:58 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nHRzE-0002xp-Dh for pgsql-hackers@arkaria.postgresql.org; Tue, 08 Feb 2022 15:00:56 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nHRzD-0002xb-Ea for pgsql-hackers@lists.postgresql.org; Tue, 08 Feb 2022 15:00:56 +0000 Received: from wout2-smtp.messagingengine.com ([64.147.123.25]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nHRz9-0001BA-3A for pgsql-hackers@postgresql.org; Tue, 08 Feb 2022 15:00:55 +0000 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 2F72B3201DDB; Tue, 8 Feb 2022 10:00:46 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Tue, 08 Feb 2022 10:00:46 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; bh=btk0uBB/3u9R5kG2T8ZxToYQcinkkG0W+54sIrIWcS4=; b=Vy+UhnVi q6btkb9ONZrUAcixCZIQb2mxhT4yGnkkLV/lS/jUDrYEdHAu56i38LyXXf4VkCbW e1mDWZM3AztPd6DGbGH529aoluv1mQm9XDW39G0NyVfQqGukj/j+BFb4kjaCq7D3 /YqkgvK7Lk3PLxIt0sKvPyNsrvOiD+4wNPEKYXkZ+M6NvFjtvz6P+4/a0yxXdgzD faJWfTLbFFVjhU0Gg77qy0BLkB9KkjvCAh9hfTITgJzgQFHKqKST8wHnUu2ci1e8 AtjXfnel3ix6I7A47biVJpYvn8p+/9x09s9DdmDzbTlsKwpZAk9h8lv3BIk+uh5t WpV7HTWhxRxqiw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrheejgdeijecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpeffhffvuffkgggtugfgjgesthekredttddtjeenucfhrhhomheptehlvhgrrhho ucfjvghrrhgvrhgruceorghlvhhhvghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrgheqne cuggftrfgrthhtvghrnhepudejveejffejveduudetvdekieeuiedtvdeileefkeevjedu feeguedvjefhueelnecuffhomhgrihhnpegvnhhtvghrphhrihhsvggusgdrtghomhenuc evlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrlhhvhhgv rhhrvgesrghlvhhhrdhnohdqihhprdhorhhg X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 8 Feb 2022 10:00:44 -0500 (EST) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id 949042A0760; Tue, 8 Feb 2022 12:00:41 -0300 (-03) Date: Tue, 8 Feb 2022 12:00:41 -0300 From: Alvaro Herrera To: Tom Lane Cc: Fabien COELHO , Peter Eisentraut , pgsql-hackers Subject: Re: libpq async duplicate error results Message-ID: <202202081500.xl3iwa7doscz@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <979911.1644253651@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 2022-Feb-07, Tom Lane wrote: > In any case, the particular example we're looking at here is connection > loss, which is not something that should greatly concern us as far as > pipeline semantics are concerned, because you're not getting any more > pipelined results anyway if that happens. In the non-I/O-error case, > I see that PQgetResult does a hacky "resetPQExpBuffer(&conn->errorMessage)" > in between pipelined queries. It seems like if there are real usability > issues in this area, they probably come from that not being well placed. > In particular, I wonder why that's done with the pqPipelineProcessQueue > call in the PGASYNC_IDLE stanza, yet not with the pqPipelineProcessQueue > call in the PGASYNC_READY stanza (where we're returning a PIPELINE_SYNC > result). It kinda looks to me like maybe pqPipelineProcessQueue > ought to have the responsibility for doing that, rather than having > two out of the three call sites do it. Also it would seem more natural > to associate it with the reinitialization that happens inside > pqPipelineProcessQueue. Yeah, I agree that the placement of error message reset in pipelined libpq is more ad-hoc to the testing I was doing than carefully principled. I didn't test changing it, but on a quick look your proposed change seems reasonable to me. -- Álvaro Herrera 39°49'30"S 73°17'W — https://www.EnterpriseDB.com/ "Pensar que el espectro que vemos es ilusorio no lo despoja de espanto, sólo le suma el nuevo terror de la locura" (Perelandra, C.S. Lewis)