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?
merlin
