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

tglsfdc · tglsfdc · commit 7321eed9e820 · 2001-12-04T01:49:17.000Z
in the parallel regression tests.  Suggest editing parallel_schedule
as a workaround if one cannot fix the system limits.
diff --git 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>
@@ -83,6 +83,21 @@
    </para>
   </note>
 
+  <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
@@ -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>
 
