Re: Testing with concurrent sessions

From: Markus Wanner <markus(at)bluegap(dot)ch>
To: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Testing with concurrent sessions
Date: 2010-01-18 16:19:08
Message-ID: 4B5489FC.1010004@bluegap.ch
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

Quoting "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Stark 2010-01-18 16:35:59 Re: Faster CREATE DATABASE by delaying fsync (was 8.4.1 ubuntu karmic slow createdb)
Previous Message Hitoshi Harada 2010-01-18 16:01:18 Review: Typed Table