From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
---|---|
To: | Daniel Verite <daniel(at)manitou-mail(dot)org> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: libpq sendQuery -- getResult not returning until all queries complete |
Date: | 2010-12-21 20:55:54 |
Message-ID: | AANLkTi=aSKV0Ukj-SB2g-9bzm5ZUEYkM8_OTFh_Hf0jG@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Tue, Dec 21, 2010 at 3:40 PM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
> On Tue, Dec 21, 2010 at 3:37 PM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
>> On Tue, Dec 21, 2010 at 3:14 PM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
>>> On Tue, Dec 21, 2010 at 3:07 PM, Daniel Verite <daniel(at)manitou-mail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Filip Rembiałkowski | 2010-12-21 21:28:27 | Re: How to use pgbouncer |
Previous Message | Merlin Moncure | 2010-12-21 20:40:53 | Re: libpq sendQuery -- getResult not returning until all queries complete |