On Tue, Dec 21, 2010 at 3:40 PM, Merlin Moncure <mmoncure@xxxxxxxxx> wrote: > On Tue, Dec 21, 2010 at 3:37 PM, Merlin Moncure <mmoncure@xxxxxxxxx> wrote: >> On Tue, Dec 21, 2010 at 3:14 PM, Merlin Moncure <mmoncure@xxxxxxxxx> wrote: >>> On Tue, Dec 21, 2010 at 3:07 PM, Daniel Verite <daniel@xxxxxxxxxxxxxxxx> 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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
