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 1lHbnD-0003g9-Ci for pgsql-hackers@arkaria.postgresql.org; Thu, 04 Mar 2021 00:24:39 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1lHbnC-0003xQ-6K for pgsql-hackers@arkaria.postgresql.org; Thu, 04 Mar 2021 00:24:38 +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 1lHbnB-0003xJ-HG for pgsql-hackers@lists.postgresql.org; Thu, 04 Mar 2021 00:24:37 +0000 Received: from wout4-smtp.messagingengine.com ([64.147.123.20]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lHbn9-0006QN-Af for pgsql-hackers@lists.postgresql.org; Thu, 04 Mar 2021 00:24:36 +0000 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 352AF1750; Wed, 3 Mar 2021 19:24:33 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Wed, 03 Mar 2021 19:24:33 -0500 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=ntTP5cs0PPWRYjASK0l5cDesikpzJYSrE7AgnqVszC4=; b=T5VAPEzY Wz55y3FS58+mCABLwcIehFvNXaTaEr2JhPE8qA5Eiik/qMyjgFDZjX/qTU4Dj3Z7 mlr5JRBgByo3QHC+s9JvaVfsVYdXF6Nmj9IPUK/5lATkqm6dLK62uBcgsELR6+LM G/youWzW+VIlCjAd1rksUyRZedHeXDg/apLwUWuhuFF7R/+jbC/IBn/+LWJ+O0W6 nl+EkeN2nqGLpG+gUU6V6YJtGArfavsqAs8mgegZiUy+FmI7z5ZybPQLSxTmxosb HP+fp600UwlzUTMpfbG/lfj7+XREEegT62MJRqV1j33BPnywc/GYgBRjRI9AEVi1 9ufmos7xlxk6og== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledruddtfedgudelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfggtggugfgjfgesmhekreertderudenucfhrhhomhepkdetlhhv rghrohcujfgvrhhrvghrrgdkuceorghlvhhhvghrrhgvsegrlhhvhhdrnhhoqdhiphdroh hrgheqnecuggftrfgrthhtvghrnhepgfdujeetfeekveetieehiedtfeehtdeugfdtuefh leehtedvtdejteffvdehffeknecukfhppeduledtrdelhedrudelrdelheenucevlhhush htvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrlhhvhhgvrhhrvges rghlvhhhrdhnohdqihhprdhorhhg X-ME-Proxy: Received: from perhan.alvh.no-ip.org (unknown [190.95.19.95]) by mail.messagingengine.com (Postfix) with ESMTPA id 2ABF2108005F; Wed, 3 Mar 2021 19:24:32 -0500 (EST) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id 5E6522A14F6; Wed, 3 Mar 2021 21:24:29 -0300 (-03) Date: Wed, 3 Mar 2021 21:24:29 -0300 From: 'Alvaro Herrera' To: "k.jamison@fujitsu.com" Cc: Craig Ringer , Matthieu Garrigues , PostgreSQL-development Subject: Re: PATCH: Batch/pipelining support for libpq Message-ID: <20210304002429.GA8225@alvherre.pgsql> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="G4iJoqBmSsgzjUCe" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20210303234241.GA22679@alvherre.pgsql> User-Agent: Mutt/1.10.1 (2018-07-13) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --G4iJoqBmSsgzjUCe Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit On 2021-Mar-03, 'Alvaro Herrera' wrote: > This should obviously not occur. I'm trying to figure out how to repair > it and not break everything again ... I think trying to set up the connection state so that the next query appears in conn->last_query prior to PQgetResult being called again leads to worse breakage. The simplest fix seems to make fe-protocol3.c aware that in this case, the query is in conn->cmd_queue_head instead, as in the attached patch. -- Álvaro Herrera 39°49'30"S 73°17'W --G4iJoqBmSsgzjUCe Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="error-fix.patch" diff --git a/src/interfaces/libpq/fe-protocol3.c b/src/interfaces/libpq/fe-protocol3.c index 584922b340..b89f500902 100644 --- a/src/interfaces/libpq/fe-protocol3.c +++ b/src/interfaces/libpq/fe-protocol3.c @@ -962,9 +962,21 @@ pqGetErrorNotice3(PGconn *conn, bool isError) * Save the active query text, if any, into res as well; but only if we * might need it for an error cursor display, which is only true if there * is a PG_DIAG_STATEMENT_POSITION field. + * + * Note that in pipeline mode, we have not yet advanced the query pointer + * to the next query, so we have to look at that. */ - if (have_position && conn->last_query && res) - res->errQuery = pqResultStrdup(res, conn->last_query); + if (have_position && res) + { + if (conn->pipelineStatus != PQ_PIPELINE_OFF && + conn->asyncStatus == PGASYNC_IDLE) + { + if (conn->cmd_queue_head) + res->errQuery = pqResultStrdup(res, conn->cmd_queue_head->query); + } + else if (conn->last_query) + res->errQuery = pqResultStrdup(res, conn->last_query); + } /* * Now build the "overall" error message for PQresultErrorMessage. --G4iJoqBmSsgzjUCe--