From 7321eed9e820d539742b965e853334a73211ab25 Mon Sep 17 00:00:00 2001 From: Tom Lane 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 907babcbf6..027ea381d1 100644 --- a/doc/src/sgml/regress.sgml +++ b/doc/src/sgml/regress.sgml @@ -1,4 +1,4 @@ - + Regression Tests @@ -85,6 +85,21 @@ + 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 + src/test/regress/parallel_schedule to split the + larger concurrent test sets into more manageable groups. + + + + + On some systems, the default Bourne-compatible shell (/bin/sh) gets confused when it has to manage too many child processes in parallel. This may cause the parallel @@ -95,6 +110,8 @@ $ gmake SHELL=/bin/ksh check + If no non-broken shell is available, you can alter the parallel test + schedule as suggested above. -- 2.11.0