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