Skip site navigation (1) Skip section navigation (2)

Re: Testing with concurrent sessions

From: "Markus Wanner" <markus(at)bluegap(dot)ch>
To: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: "Michael Tan" <mtanhl(at)gmail(dot)com>, david(at)kineticode(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Testing with concurrent sessions
Date: 2010-01-15 15:22:04
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers

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.



In response to


pgsql-hackers by date

Next:From: Kevin GrittnerDate: 2010-01-15 15:34:16
Subject: Re: Testing with concurrent sessions
Previous:From: Kevin GrittnerDate: 2010-01-15 15:09:31
Subject: Re: Testing with concurrent sessions

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group