Re: Going for "all green" buildfarm results

On Thu, Aug 17, 2006 at 04:17:01PM +0100, stark wrote:
> I wanted to test the online index build and to do that I figured you needed to
> have regression tests like the ones we have now except with multiple database
> sessions. So I hacked psql to issue queries asynchronously and allow multiple
> database connections. That way you can switch connections while a blocked or
> slow transaction is still running and issue queries in other transactions.

Wow, that's damn cool! FWIW, one thing I can think of that would be
useful is the ability to 'background' a long-running query. I see
\cnowait, but having something like & from unix shells would be even
easier. It'd also be great to have the equivalent of ^Z so that if you
got tired of waiting on a query, you could get back to the psql prompt
without killing it.

> Also, I think for interactive use we would want a somewhat more sophisticated
> scheduling of output. It would be nice to print out results as they come in
> even if we're on another connection. For the regression tests you certainly do
> not want that since that would introduce unavoidable non-deterministic race
> conditions in your output files all over the place. The way I've coded it now
> takes care to print out output only from the "active" database connection and
> the test cases need to be written to switch connections at each point they
> want to test for possibly incorrect output.

Thinking in terms of tcsh & co, there's a number of ways to handle this:

1) Output happens real-time
2) Only output from current connection (what you've done)
3) Only output after user input (ie: code that handles output is only
run after the user has entered a command). I think most shells
operate this way by default.
4) Provide an indication that output has come in from a background
connection, but don't provide the actual output. This could be
combined with #3.

#3 is nice because you won't get interrupted in the middle of entering
some long query. #4 could be useful for automated testing, especially if
the indicator was routed to another output channel, such as STDERR.

> Another issue was that I couldn't come up with a nice set of names for the
> commands that didn't conflict with the myriad of one-letter commands already
> in psql. So I just prefixed the all with "c" (connection). I figured when I
> submitted it I would just let the community hash out the names and take the 2s
> it would take to change them.
>
> The test cases are actually super easy to write and read, at least considering
> we're talking about concurrent sql sessions here. I think it's far clearer
> than trying to handle separate scripts and nearly as clear as Martin's
> proposal from a while back to prepend a connection number on every line.
>
> The commands I've added or altered are:
>
> \c[onnect][&] [DBNAME|- USER|- HOST|- PORT|-]
> connect to new database (currently "postgres")
> if optional & is present open do not close existing connection
> \cswitch n
> switch to database connection n

I can see \1 - \9 as being a handy shortcut.
> \clist
> list database connections
> \cdisconnect
> close current database connection
> use \cswitch or \connect to select another connection

Would ^d have the same effect?
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461