Document max-processes-per-user limit as a possible cause of failures

in the parallel regression tests.  Suggest editing parallel_schedule
as a workaround if one cannot fix the system limits.

1 files changed, 18 insertions, 1 deletions

diff --git a/doc/src/sgml/regress.sgml b/doc/src/sgml/regress.sgml
index 907babcbf6e..027ea381d11 100644
--- a/doc/src/sgml/regress.sgml
+++ b/doc/src/sgml/regress.sgml
@@ -1,4 +1,4 @@
-<!-- $Header: /cvsroot/pgsql/doc/src/sgml/regress.sgml,v 1.22 2001/11/28 20:49:10 petere Exp $ -->
+<!-- $Header: /cvsroot/pgsql/doc/src/sgml/regress.sgml,v 1.23 2001/12/04 01:49:17 tgl Exp $ -->
 
  <chapter id="regress">
   <title id="regress-title">Regression Tests</title>
@@ -85,6 +85,21 @@
 
   <tip>
    <para>
+    The parallel regression test starts quite a few processes under your
+    userid.  Presently, the maximum concurrency is twenty parallel test
+    scripts, which means sixty processes --- there's a backend, 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
+    <filename>src/test/regress/parallel_schedule</> to split the
+    larger concurrent test sets into more manageable groups.
+   </para>
+  </tip>
+
+  <tip>
+   <para>
     On some systems, the default Bourne-compatible shell
     (<filename>/bin/sh</filename>) gets confused when it has to manage
     too many child processes in parallel.  This may cause the parallel
@@ -95,6 +110,8 @@
 <prompt>$ </prompt><userinput>gmake SHELL=/bin/ksh check</userinput>
 </screen>
     </informalexample>
+    If no non-broken shell is available, you can alter the parallel test
+    schedule as suggested above.
    </para>
   </tip>