On Wed, Feb 15, 2017 at 11:08 AM, Robert Haas <robertmh...@gmail.com> wrote: > I think the patch as presented probably isn't quite what we want, > because it waits synchronously for the second result to be ready. > Note that the wait for the first result is asynchronous: we check > PQisBusy and return without progressing the state machine until the > latter returns false; only then do we call PQgetResult().
OK, I have been poking at this problem. I think that we need to introduce a new state in ConnStatusType telling "please consume all results until PQgetResult returns NULL" which is CONNECTION_CONSUME in the patch attached. And as long as all the results are not consumed, the loop just keeps going. If more messages are being waited for with PGisBusy returning true, then the loop requests for more data to read by switching back to PGRES_POLLING_READING. By the way, I am noticing as well that libpq.sgml is missing a reference to CONNECTION_CHECK_WRITABLE. This should be present as applications calling PQconnectPoll() could face such a status. I have fixed this issue as well in the patch attached. -- Michael
pqsendquery-fix-v3.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
