Re: Testing with concurrent sessions

Hi,

Quoting "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>:
> I haven't quite gotten it to work yet; I'll start over with 3.0 and
> see how it goes.

Let's stick to 2.x versions, first...

> I'll also attach the results of the 2.6 attempt.

Thanks, that looks already pretty promising. ;-)

> A few other issues in testing so far:
>
> (1) I see that a 'make dcheck' does a 'make install'. That's not
> right. For one thing I usually install in a location where I need
> to sudo to install; but more importantly, I want to do all checks
> *before* I install. It's easy enough to work around that for now,
> but I don't think it's acceptable long-term.

It does: "temp_install: creating temporary installation" means it's
running make install in the background.

> (2) After a 'make dcheck' failure, the cluster created for the
> testing is left running.

That counts as a bug. I also get that from time to time (and with
Postgres-R testing on 3+ instances, it's even more annoying).

Note that the error just before that is, that a psql process it starts
cannot connect to its postmaster ("startup of test test-conn-0A
failed, skipping.") Please check the log
(src/test/regress/dtester.log) for why that failed in the first place.
Can you connect manually to the database (that's still running after a
make dcheck)?

> (3) If the install could check dependencies, report problems, and
> refuse to install without required packages, that would be less
> confusing for python novices (like me).

I'm not exactly a distutils hacker... Anybody else got any clue here?

> Perhaps some of these problems will go away with python 3.0, but I
> figured I should pass the info along.

I'd rather suspect that more of them will arise.

Regards

Markus