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 [EMAIL PROTECTED] Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match