Date: Wed, 3 Mar 2021 20:42:41 -0300
From: 'Alvaro Herrera' <alvherre@alvh.no-ip.org>
To: "k.jamison@fujitsu.com" <k.jamison@fujitsu.com>
Cc: Craig Ringer <craig.ringer@enterprisedb.com>,
	Matthieu Garrigues <matthieu.garrigues@gmail.com>,
	PostgreSQL-development <pgsql-hackers@lists.postgresql.org>
Subject: Re: PATCH: Batch/pipelining support for libpq
Message-ID: <20210303234241.GA22679@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20210303163430.GA24777@alvherre.pgsql>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: 
 <https://www.postgresql.org/message-id/20210303234241.GA22679%40alvherre.pgsql>
Precedence: bulk

On 2021-Mar-03, 'Alvaro Herrera' wrote:

> I'm much more comfortable with this version, so I'm marking the patch as
> Ready for Committer in case anybody else wants to look at this before I
> push it.

Actually, I just noticed a pretty serious problem, which is that when we
report an error, we don't set "conn->errQuery" to the current query but
to the *previous* query, leading to non-sensical error reports like

$ ./pipeline pipeline_abort
aborted pipeline... ERROR:  no existe la función no_such_function(integer)
LINE 1: INSERT INTO pq_pipeline_demo(itemno) VALUES ($1);
               ^
HINT:  Ninguna función coincide en el nombre y tipos de argumentos. Puede ser necesario agregar conversión explícita de tipos.
ok


(Sorry about the Spanish there, but the gist of the problem is that
we're positioning the error cursor on a query that succeeded prior to
the query that raised the error.)

This should obviously not occur.  I'm trying to figure out how to repair
it and not break everything again ...

-- 
Álvaro Herrera       Valdivia, Chile