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. merlin -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
