From 7321eed9e820d539742b965e853334a73211ab25 Mon Sep 17 00:00:00 2001
From: Tom Lane <tgl@sss.pgh.pa.us>
Date: Tue, 4 Dec 2001 01:49:17 +0000
Subject: [PATCH] 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.
---
doc/src/sgml/regress.sgml | 19 ++++++++++++++++++-
1 file changed, 18 insertions(+), 1 deletion(-)
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>
@@ -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>
--
GitLab