Feedback-ID: ia2694551:Fastmail
Date: Wed, 21 Dec 2022 20:41:20 +0100
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: dynamic result sets support in extended query protocol
Message-ID: <20221221194120.wttku6u7cbd6e574@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <e7a8f472-9664-d33f-848f-5bf1fa0586b1@enterprisedb.com>
Archived-At: 
 <https://www.postgresql.org/message-id/20221221194120.wttku6u7cbd6e574%40alvherre.pgsql>
Precedence: bulk

On 2022-Nov-22, Peter Eisentraut wrote:

> I added tests using the new psql \bind command to test this functionality in
> the extended query protocol, which showed that this got broken since I first
> wrote this patch.  This "blame" is on the pipeline mode in libpq patch
> (acb7e4eb6b1c614c68a62fb3a6a5bba1af0a2659).  I need to spend more time on
> this and figure out how to repair it.  In the meantime, here is an updated
> patch set with the current status.

I looked at this a little bit to understand why it fails with \bind.  As
you say, it does interact badly with pipeline mode -- more precisely, it
collides with the queue handling that was added for pipeline.  The
problem is that in extended query mode, we "advance" the queue in
PQgetResult when asyncStatus is READY -- fe-exec.c line 2110 ff.  But
the protocol relies on returning READY when the second RowDescriptor
message is received (fe-protocol3.c line 319), so libpq gets confused
and everything blows up.  libpq needs the queue to stay put until all
the results from that query have been consumed.

If you comment out the pqCommandQueueAdvance() in fe-exec.c line 2124,
your example works correctly and no longer throws a libpq error (but of
course, other things break).

I suppose that in order for this to work, we would have to find another
way to "advance" the queue that doesn't rely on the status being
PGASYNC_READY.

-- 
Álvaro Herrera        Breisgau, Deutschland  —  https://www.EnterpriseDB.com/