Re: [HACKERS] psql & regress tests

Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
>
> > Any modifications to shared pg_ tables would be a problem. Also, pg_log
> > and pg_variable locking is not happening in there either, is it?
>
> Good point --- it wouldn't be just that database, but the whole
> installation (data directory) that would have to be unused. You really
> wouldn't dare even have a postmaster running, at least not in the same
> data directory. But that could be made safe by using a nonstandard
> location for the data directory for regression.
>
> However, this is all beside the main point: we want the regress tests
> to run in an environment as close as possible to the way Postgres is
> normally used. The more we hack up a special regress-test environment,
> the less the tests reflect reality.

My new script actually does a

make POSTGRESDIR=somewhere_else install
PATH="somewhere_else/bin:$PATH"

Then it initializes a database below there and starts a
postmaster with the resulting data directory, listening on
port 65432.

So I think it's very close to a real live setup, while
another "production" running installation isn't affected at
all.

> Aside from the cross-backend synchronization issue, I forgot to point
> out a really obvious benefit: doing it the current way allows the regress
> tests to help check the backend's frontend communication code, and
> libpq, and psql itself. We'd need some other way of testing all that
> code if we switched to a standalone-backend regression test set.
>
> What I *would* like to see is more support for running regress tests on
> a not-yet-installed build, so people can test a fresh build before they
> blow away their working installation. This requires doing an initdb
> into a temporary directory, starting a postmaster therein (using a
> nonstandard port number), and running the tests there. This is doable
> by hand, of course, but it's tedious and error-prone even for an expert;
> I think it's out of the question for a novice installer. We ought to
> offer a canned script to do it that way.

Right, right, right - I'm on it.

The ugly detail, I'm currently running into, is that there
already seems to be a concurrency problem I discovered with
my testing. Occationally I get this into the postmaster log
for parallel executing tests:

ERROR: Bad boolean external representation 'XXX'
FATAL 1: SearchSysCache: recursive use of cache 10
FATAL 2: elog: error in postmaster or backend startup, giving up!
pq_flush: send() failed: Broken pipe
Server process (pid 9791) exited with status 512 at Fri Nov 19 03:17:09 1999
Terminating any active server processes...

It happens during the first parallel group of 11 tests. Not
allways, so it's timing critical. Outch.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck(at)debis(dot)com (Jan Wieck) #