From: | 'Alvaro Herrera' <alvherre(at)alvh(dot)no-ip(dot)org> |
---|---|
To: | "k(dot)jamison(at)fujitsu(dot)com" <k(dot)jamison(at)fujitsu(dot)com> |
Cc: | Craig Ringer <craig(dot)ringer(at)enterprisedb(dot)com>, Matthieu Garrigues <matthieu(dot)garrigues(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: PATCH: Batch/pipelining support for libpq |
Date: | 2021-03-03 23:42:41 |
Message-ID: | 20210303234241.GA22679@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2021-03-03 23:44:02 | Re: Removing support for COPY FROM STDIN in protocol version 2 |
Previous Message | Tom Lane | 2021-03-03 23:32:58 | Re: Removing support for COPY FROM STDIN in protocol version 2 |