Re: Concurrent psql patch

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: "Andrew Dunstan" <andrew(at)dunslane(dot)net>
Cc: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "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 16:41:09
Message-ID: 87iraboa56.fsf@oxford.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

"Andrew Dunstan" <andrew(at)dunslane(dot)net> writes:

> Tom Lane wrote:
>> 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().

Oh, now I remember why I'm including libpq-int.h. It's not for PGASYNC_BUSY as
above. The case above can indeed be fixed using PQIsBusy() (and select/poll
looping).

The missing interface is for PGASYNC_IDLE. The problem is that I didn't really
want to have psql go through the trouble to check all the connections for
waiting output if it didn't have any queries pending.

This could be fixed by having psql track which connections are waiting for
query results. It's a bit annoying to have two state bits that hold the same
data at two different levels of abstraction though.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2007-05-29 17:00:57 Re: TOAST usage setting
Previous Message Bruce Momjian 2007-05-29 16:32:53 Re: TOAST usage setting

Browse pgsql-patches by date

  From Date Subject
Next Message Gregory Stark 2007-05-29 17:02:51 Re: Concurrent psql patch
Previous Message Alvaro Herrera 2007-05-29 15:50:26 Re: Seq scans status update