From eeaf5f04ae3fca446b43851fb9a612fe0c980994 Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Sun, 2 Nov 2003 21:56:15 +0000 Subject: Provide a way to run the parallel regression tests with a user-specified limit on the number of simultaneous connections. Andrew Dunstan, with review by Tom Lane. --- doc/src/sgml/regress.sgml | 34 +++++++++++++++++++--------------- 1 file changed, 19 insertions(+), 15 deletions(-) (limited to 'doc/src') diff --git a/doc/src/sgml/regress.sgml b/doc/src/sgml/regress.sgml index 768f0cf6ea0..693a7583735 100644 --- a/doc/src/sgml/regress.sgml +++ b/doc/src/sgml/regress.sgml @@ -1,4 +1,4 @@ - + Regression Tests @@ -52,18 +52,18 @@ gmake check ====================== - All 77 tests passed. + All 93 tests passed. ====================== - or otherwise a note about what tests failed. See below for more. Because this test method runs a temporary server, it will not work - when you are the root user (the server will not start as root). + when you are the root user (since the server will not start as root). If you already did the build as root, you do not have to start all over. Instead, make the regression test directory writable by some other user, log in as that user, and restart the tests. @@ -88,14 +88,18 @@ gmake check The parallel regression test starts quite a few processes under your user ID. Presently, the maximum concurrency is twenty parallel test - scripts, which means sixty processes: there's a server process, a psql, - and usually a shell parent process for the psql for each test script. + scripts, which means sixty processes: there's a server process, a + psql, and usually a shell parent process for the + psql for each test script. So if your system enforces a per-user limit on the number of processes, make sure this limit is at least seventy-five or so, else you may get random-seeming failures in the parallel test. If you are not in - a position to raise the limit, you can edit the file - src/test/regress/parallel_schedule to split the - larger concurrent test sets into more manageable groups. + a position to raise the limit, you can cut down the degree of parallelism + by setting the MAX_CONNECTIONS parameter. For example, + +gmake MAX_CONNECTIONS=10 check + + runs no more than ten tests concurrently. @@ -109,8 +113,8 @@ gmake check gmake SHELL=/bin/ksh check - If no non-broken shell is available, you can alter the parallel test - schedule as suggested above. + If no non-broken shell is available, you may be able to work around the + problem by limiting the number of connections, as shown above. @@ -177,7 +181,7 @@ gmake installcheck If you run the tests against an already-installed server that was - initialized with a collation order locale different than C then + initialized with a collation-order locale other than C, then there may be differences due to sort order and follow-up failures. The regression test suite is set up to handle this problem by providing alternative result files that together are @@ -199,7 +203,7 @@ gmake installcheck testname_digit.out. The actual digit is not significant. Remember that the regression test driver will consider all such files to be equally - valid test results. If the test results are platform-dependent, + valid test results. If the test results are platform-specific, the technique described in should be used instead. @@ -245,7 +249,7 @@ env TZ=PST8PDT date The command above should have returned the current system time in the PST8PDT time zone. If the PST8PDT time zone is not available, - then your system may have returned the time in GMT. If the + then your system may have returned the time in UTC. If the PST8PDT time zone is missing, you can set the time zone rules explicitly: @@ -364,7 +368,7 @@ diff results/random.out expected/random.out which comparison file to use. So, to eliminate bogus test failures for a particular platform, you must choose or make a variant result file, and then add a line to the mapping - file, which is resultmap. + file, which is src/test/regress/resultmap. -- cgit v1.2.3