Re: Testing with concurrent sessions

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

[off-list to avoid distracting from the 9.0 wrap-up effort]

Markus Wanner <markus(at)bluegap(dot)ch> wrote:
> 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 just got to the point of having what appears to be a working but
poorly optimized version of serializable transactions, so it is
critical that I create a good set of tests to confirm correct
behavior and monitor for regressions as I optimize. I see that
you've been working on dtester recently -- should I grab what you've
got here, stick with 0.1, or do you want to package something? If I
should pull from your git, any hints on the best git statements to
merge that in are welcome, I'm still rather new to git, and I tend
not to get things right on a first try without some hints. :-/

Thanks again for this tool!

-Kevin

I wrote:
> [off-list to avoid distracting from the 9.0 wrap-up effort]

Arg. I really didn't mean that to go to the list. :-(

-Kevin

Hi,

Kevin Grittner wrote:
> I just got to the point of having what appears to be a working but
> poorly optimized version of serializable transactions,

Cool.

> so it is
> critical that I create a good set of tests to confirm correct
> behavior and monitor for regressions as I optimize. I see that
> you've been working on dtester recently -- should I grab what you've
> got here, stick with 0.1, or do you want to package something?

I'm preparing for a 0.1 release, yes. However, I'm trying to keep up
with the postgres-dtests branch, so that should continue to work with
the latest dtester code.

> If I
> should pull from your git, any hints on the best git statements to
> merge that in are welcome, I'm still rather new to git, and I tend
> not to get things right on a first try without some hints. :-/

I'd recommend merging postgres-dtests into your branch, so you'll get
all of the adjustments from there, if I change dtester itself.

Once 0.1 is out, I'm *trying* to remain backwards compatible in future
releases. However, that holds me from releasing 0.1 in the first place :-)

Independent of versions and releases: if you build your tests on top of
dtester, I'm more than willing to support you with that. If you keep
your code in a git repository, I could even provide patches, in case I
need (or want) to change the dtester interface.

Regards

Markus Wanner