Re: Concurrent connections in psql

Поиск
Список
Период
Сортировка
От Jim C. Nasby
Тема Re: Concurrent connections in psql
Дата
Msg-id 20070121080130.GC77382@nasby.net
обсуждение исходный текст
Ответ на Re: Concurrent connections in psql  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-hackers
Sounds like good reason to get it in early... :)

It would be nice if there were some tests for this/that used this...
wasn't there a patch for that floating around somewhere?

On Sat, Jan 20, 2007 at 05:11:25PM -0500, Bruce Momjian wrote:
> 
> What are people's opinions on this patch?  (It is at the URL below.)
> 
> I like the capability, and am impressed it allowed testing that found
> some concurrency bugs in our server, but it is a large patch to psql.
> 
> ---------------------------------------------------------------------------
> 
> Gregory Stark wrote:
> > 
> > I mentioned this a while back, now that 8.2 is out perhaps others will be more
> > interested in new code.
> > 
> > Currently Postgres regression tests only test functionality within a single
> > session. There are no regression tests that test the transaction semantics or
> > locking behaviour across multiple transactions.
> > 
> > I modified psql to allow you to open multiple connections and switch between
> > them with a sort of csh job control style interface. It actually works out
> > pretty well. It's fairly easy to write regression tests for basic 2-client or
> > 3-client cases.
> > 
> > The actual user interface may need some discussion though. I didn't want to
> > play the name game so I just prefixed all my commands with "c" and figured we
> > can always rename them later.
> > 
> > And experience with actually writing the tests shows that the explicit \cwait
> > command which was needed to eliminate (in practice if not in theory) race
> > conditions in regression tests turns out to be more flexibility than
> > necessary. Since you end up having to insert one in precisely predictable
> > locations -- namely after every asynchronous command and after every
> > connection switch -- perhaps it would be simpler to just have a "\pset cwait"
> > command that automatically introduces timeouts in precisely those places.
> > 
> > A brief explanation including an example regression test (the SAVEPOINT
> > locking bug discovered recently) and the patch here:
> > 
> >   http://community.enterprisedb.com/concurrent/index.html
> > 
> > -- 
> >   Gregory Stark
> >   EnterpriseDB          http://www.enterprisedb.com
> > 
> > 
> > ---------------------------(end of broadcast)---------------------------
> > TIP 5: don't forget to increase your free space map settings
> 
> -- 
>   Bruce Momjian   bruce@momjian.us
>   EnterpriseDB    http://www.enterprisedb.com
> 
>   + If your life is a hard drive, Christ can be your backup. +
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
> 

-- 
Jim Nasby                                            jim@nasby.net
EnterpriseDB      http://enterprisedb.com      512.569.9461 (cell)


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: XML regression test failure
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: ECPG regression tests seem rather fundamentally broken