Date: Wed, 3 Mar 2021 22:51:08 -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: <20210304015108.GA15670@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20210304002429.GA8225@alvherre.pgsql>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: 
 <https://www.postgresql.org/message-id/20210304015108.GA15670%40alvherre.pgsql>
Precedence: bulk

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

> 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.

I wonder if it would make sense to get rid of conn->last_query
completely and just rely always on conn->cmd_queue_head, where the
normal (non-pipeline) would use the first entry of the command queue.
That might end up being simpler than pipeline mode "pretending" to take
over ->last_query.

-- 
Álvaro Herrera                            39°49'30"S 73°17'W
"La verdad no siempre es bonita, pero el hambre de ella sí"