"Tom Lane" <[EMAIL PROTECTED]> writes:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
>> if (pset.c->db->asyncStatus != PGASYNC_BUSY)
>> {
>> break;
>> }
>
> There already is a defined API for this, namely PQisBusy().
>
> In any case, I rather concur with the XXX comment: busy-waiting like
> this sucks. The correct way to do this is to get the socket numbers for
> the connections (via PQsocket), wait for any of them to be read-ready
> according to select() (or for the timeout to elapse, assuming that we
> think that behavior is good), then cycle through PQconsumeInput() and
> PQisBusy() on each connection. See
> http://www.postgresql.org/docs/8.2/static/libpq-async.html
Huh, so it turns out we already have code that does exactly this in
pqSocketPoll and pqSocketCheck. Except that they have too little resolution
because they work with time_t which means we would have to wait at least 1-2
seconds.
And pqSocketCheck keeps looping when it gets an EINTR which doesn't seem like
the right thing for psql to do.
It would be nice to use these functions though because:
a) They get the SSL case right in that that they check the SSL buffer before
calling select/poll.
b) They use poll if available and fall back to select
c) they would keep the select/poll system code out of psql where there's none
of it currently.
So would I be better off adding a PQSocketPollms() which works in milliseconds
instead of seconds? Or should I just copy all this code into psql?
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
