Re: Concurrent psql API - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Concurrent psql API
Date
Msg-id 20080408221910.GT9062@alvh.no-ip.org
Whole thread Raw
In response to Re: Concurrent psql API  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Concurrent psql API  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> I wrote:
> > What seems possibly more useful is to reintroduce \cwait (or hopefully
> > some better name) and give it the semantics of "wait for a response from
> > any active connection; switch to the first one to respond, printing its
> > name, and print its result".
> 
> It strikes me that with these semantics, \cwait is a lot like a thread
> join operation, so we could call it \join or \j.

FWIW on POSIX shell there's something similar called "wait".

http://www.opengroup.org/onlinepubs/009695399/utilities/wait.html

Perhaps we should define the operator after these semantics -- these
guys have probably hashed up a good interface.  Basically it means we
would have a "\cwait [n ...]" command meaning "wait for the connection
'n' to return".

If we do that, we can then have multiple commands in flight on
regression tests, and wait for them in whatever deterministic order we
choose, regardless of which one finishes execution first.

However, the no-operands version of POSIX wait means "wait for all
commands" instead of "wait for any command".  Perhaps we could have
"\cwait -" as meaning "wait for any command".

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support


pgsql-hackers by date:

Previous
From: "Stephen Denne"
Date:
Subject: Re: Allow COPY from STDIN to absorb all input before throwing an error
Next
From: Andrew Chernow
Date:
Subject: Re: [PATCHES] libpq type system 0.9a