Re: Testing with concurrent sessions

Поиск
Список
Период
Сортировка
От Markus Wanner
Тема Re: Testing with concurrent sessions
Дата
Msg-id 4B5489FC.1010004@bluegap.ch
обсуждение исходный текст
Ответ на Testing with concurrent sessions  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Ответы Re: Testing with concurrent sessions  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Список pgsql-hackers
Hi,

Quoting "Kevin Grittner" <Kevin.Grittner@wicourts.gov>:
> I strongly encourage you to set that up on git.postgresql.org.

I'm about to provide git repositories for Postgres-R anyway, so I've
setup two projects on git.postgres-r.org:

dtester: that's the driver/harness code
postgres-dtests: a Postgres clone with the dtester patch applied - this 
is based on the Postgres git repository, so you can easily switch 
between Postgres branches.

I'd like to clean postgres-dtests in the sense that all tests included
there are expected to succeed on Postgres HEAD. Those (like the
initial SSI ones) that are expected to fail should get marked as such
in there.

If you want to add SSI specific tests, which your are expecting to
succeed on your branch, I'd recommend you create your own branch
(or merge into your branch from postgres-dtests). Git makes that simple 
enough.

> I've barely scratched the surface on git in the last few
> weeks, and already I'm a big fan.  I was never convinced that
> subversion was an improvement over cvs -- they each had advantages
> over the other which seemed a wash for me -- but git takes everything
> to a whole new level.

I agree, and would like to extend that to DVCSes in general. Having 
started with monotone, I'm used to a different level of convenience, 
especially WRT network exchange and merging. To be fair, I'm excited 
about how fast git is (especially WRT network exchange, where monotone 
just plain sucks).

> I see your point.  Even with a general solution, probably best to
> leave the pset there for psql, though.

Agreed, that's fixed in the new git repository.

> I'll look those over.  Any caveats beyond what you already mentioned
> of which I should be particularly careful?

Uh.. no, there's no difference other than that. It's a paradigm
question. Ones like it that way, others the other. And then there are 
applications that are a better fit than others...

Now, I tend towards the event based approach, because it basically
relieves you from having to deal with concurrent threads and all their
issues. You need to get a single ordering of events anyway, if you want 
to check ordering constraints.

Regards

Markus


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

Предыдущее
От: Hitoshi Harada
Дата:
Сообщение: Review: Typed Table
Следующее
От: Greg Stark
Дата:
Сообщение: Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)