Re: libpq sendQuery -- getResult not returning until all queries complete

On Tue, Dec 21, 2010 at 3:40 PM, Merlin Moncure <mmoncure@gmail.com> wrote:
> On Tue, Dec 21, 2010 at 3:37 PM, Merlin Moncure <mmoncure@gmail.com> wrote:
>> On Tue, Dec 21, 2010 at 3:14 PM, Merlin Moncure <mmoncure@gmail.com> wrote:
>>> On Tue, Dec 21, 2010 at 3:07 PM, Daniel Verite <daniel@manitou-mail.org> wrote:
>>>>        Kelly Burkhart wrote:
>>>>
>>>>> #define COMMANDS "select current_timestamp; select pg_sleep(5); select
>>>>> current_timestamp"
>>>>
>>>> You should use current_clock() instead of current_timestamp, because
>>>> current_timestamp returns a fixed value throughout a transaction.
>>>
>>> Well, that's correct, but irrelevant -- Kelly's analysis is correct.
>>> The documentation for PQgetResult states:
>>>
>>> "Using PQsendQuery and PQgetResult solves one of PQexec's problems: If
>>> a command string contains multiple SQL commands, the results of those
>>> commands can be obtained individually. (This allows a simple form of
>>> overlapped processing, by the way: the client can be handling the
>>> results of one command while the server is still working on later
>>> queries in the same command string.) However, calling PQgetResult will
>>> still cause the client to block until the server completes the next
>>> SQL command. This can be avoided by proper use of two more functions:"
>>>
>>> but control is not returned until all three queries have resolved.
>>> this is probably an issue with libpq.  investigating...
>>
>> hm, it looks like the backend is not flushing the command complete for
>> each command until finishing all the queries.  This is what signals
>> libpq that a particular command has been executed.
>
> to see this in action, you can interject a query between queries 1 & 2
> that sends a lot of data. the 'lots of data' forces query one protocol
> to flush out, which the client handles properly.  this is likely
> backend bug -- it needs to force a flush upon command completion?

hm, a pq_flush() after command completion putmessage in
backend/tcop/dest.c seems to fix the problem.  I'll send up a patch to
-hackers.  They might backpatch it, unless there is a good reason not
to do this (I can't think of any).

merlin