Re: Concurrent psql patch - Mailing list pgsql-patches
From | Andrew Dunstan |
---|---|
Subject | Re: Concurrent psql patch |
Date | |
Msg-id | 4655F794.2090900@dunslane.net Whole thread Raw |
In response to | Re: Concurrent psql patch (Tom Lane <tgl@sss.pgh.pa.us>) |
Responses |
Re: Concurrent psql patch
|
List | pgsql-patches |
Tom Lane wrote: > Andrew Dunstan <andrew@dunslane.net> writes: > >> Tom Lane wrote: >> >>> If there's more needed here, let's see an official API change, >>> not a hack. >>> > > >> Well, I guess the obvious API would be something like: >> PGAsyncStatusType PQasyncStatus(const PGconn *conn); >> > > That would mean exposing PGAsyncStatusType, which doesn't seem like an > amazingly good idea either. What is it that the patch actually wants > to do? > The relevant snippet in command.c says: /* If we have async_delay set then we need to allow up to that many * milliseconds for any responses to come in on *either* connection. * This ensures that results are printed in a relatively deterministic * order for regression tests. Note that we only have to allow for n * milliseconds total between the two connections so we don't reset the * timer for the second wait. * * XXX this should maybe be changed to a select/poll loop instead */ if (pset.async_delay > 0 && pset.c->db) { GETTIMEOFDAY(&start); do { if (pset.c->db->asyncStatus != PGASYNC_BUSY) { break; } if (CheckQueryResults()) { ReadQueryResults(); break; } pg_usleep(10000); GETTIMEOFDAY(&now); } while (DIFF_MSEC(&now, &start) < pset.async_delay); } pset.c = &cset[slot-1]; printf(_("[%d] You are now connected to database \"%s\"\n"), slot, PQdb(pset.c->db)); if (pset.async_delay > 0 && pset.c->db) { do { if (pset.c->db->asyncStatus != PGASYNC_BUSY) break; if (CheckQueryResults()) { ReadQueryResults(); break; } pg_usleep(10000); GETTIMEOFDAY(&now); } while (DIFF_MSEC(&now, &start) < pset.async_delay); } and in mainloop.c it's used like this: if (pset.c->db && pset.c->db->asyncStatus != PGASYNC_IDLE && CheckQueryResults()) { ReadQueryResults(); /* If we processed a query cancellation cancel_pressed may still be * set and will interrupt the processing of the next command unless * we start the main loop over to reset it. */ if (cancel_pressed) break; } cheers andrew
pgsql-patches by date: