Skip site navigation (1) Skip section navigation (2)

Re: Concurrent psql patch

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Andrew Dunstan" <andrew(at)dunslane(dot)net>, "David Fetter" <david(at)fetter(dot)org>, "Jim Nasby" <decibel(at)decibel(dot)org>, "pgsql-patches" <pgsql-patches(at)postgresql(dot)org>
Subject: Re: Concurrent psql patch
Date: 2007-05-29 17:02:51
Message-ID: 87ejkzo950.fsf@oxford.xeocode.com (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> Andrew Dunstan <andrew(at)dunslane(dot)net> 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


In response to

pgsql-hackers by date

Next:From: Gregory StarkDate: 2007-05-29 17:06:47
Subject: Re: TOAST usage setting
Previous:From: Bruce MomjianDate: 2007-05-29 17:00:57
Subject: Re: TOAST usage setting

pgsql-patches by date

Next:From: Heikki LinnakangasDate: 2007-05-29 17:23:16
Subject: Re: Seq scans status update
Previous:From: Gregory StarkDate: 2007-05-29 16:41:09
Subject: Re: Concurrent psql patch

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group