Re: Going for "all green" buildfarm results
От | Jim C. Nasby |
---|---|
Тема | Re: Going for "all green" buildfarm results |
Дата | |
Msg-id | 20060817201512.GE21363@pervasive.com обсуждение исходный текст |
Ответ на | Re: Going for "all green" buildfarm results (stark <stark@enterprisedb.com>) |
Список | pgsql-hackers |
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 thinkmost 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. Thiscould 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@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
В списке pgsql-hackers по дате отправления: