option for the final installation,
    however.
   </para>

   <para>
    The parallel regression test starts quite a few processes under your
    user ID.  Presently, the maximum concurrency is twenty parallel test
    scripts, which means forty processes: there's a server process and a
    <application>psql</application> process 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 fifty or so, else you might get
    random-seeming failures in the parallel test.  If you are not in
    a position to raise the limit, you can cut down the degree of parallelism
    by setting the <literal>MAX_CONNECTIONS</literal> parameter.  For example:
<screen>
make MAX_CONNECTIONS=10 check
</screen>
    runs no more than ten tests concurrently.
   </para>
  </sect2>

  <sect2 id="regress-run-existing-inst">
   <title>Running the Tests Against an Existing Installation</title>

  <para>
   To run the tests after installation (see <xref linkend="installation"/>),
   initialize a data directory and start the
   server as explained in <xref linkend="runtime"/>, then type:
<screen>
make installcheck
</screen>
or for a parallel test:
<screen>
make installcheck-parallel
</screen>
   The tests will expect to contact the server at the local host and the
   default port number, unless directed otherwise by <envar>PGHOST</envar> and
   <envar>PGPORT</envar> environment variables.  The tests will be run in a
   database named <literal>regression</literal>; any existing database by this name
   will be dropped.
  </para>

  <para>
   The tests will also transiently create some cluster-wide objects, such as
   roles, tablespaces, and subscriptions.  These objects will have names
   beginning with <literal>regress_</literal>.  Beware of
   using <literal>installcheck</literal> mode with an installation that has
   any actual global objects named that way.
  </para>
  </sect2>

  <sect2 id="regress-additional">
   <title>Additional Test Suites</title>

  <para>
   The <literal>make check</literal> and <literal>make installcheck</literal> commands
   run only the <quote>core</quote> regression tests, which test built-in
   functionality of the <productname>PostgreSQL</productname> server.  The source
   distribution contains many additional test suites, most of them having
   to do with add-on functionality such as optional procedural languages.
  </para>

  <para>
   To run all test suites applicable to the modules that have been selected
   to be built, including the core tests, type one of these commands at the
   top of the build tree:
<screen>
make check-world
make installcheck-world
</screen>
   These commands run the tests using temporary servers or an
   already-installed server, respectively, just as previously explained
   for <literal>make check</literal> and <literal>make installcheck</literal>.  Other
   considerations are the same as previously explained for each method.
   Note that <literal>make check-world</literal> builds a separate instance
   (temporary data directory) for each tested module, so it requires more
   time and disk space than <literal>make installcheck-world</literal>.
  </para>

  <para>
   On a modern machine with multiple CPU cores and no tight operating-system
   limits, you can make things go substantially faster with parallelism.
   The recipe that most PostgreSQL developers actually use for running all
   tests is something like
<screen>
make check-world -j8 >/dev/null
</screen>
   with a <option>-j</option> limit near to or a bit more than the number
   of available cores.  Discarding <systemitem>stdout</systemitem>
   eliminates chatter that's not interesting when you just want to verify
   success.  (In case of failure, the <systemitem>stderr</systemitem>
   messages are usually enough to determine where to look closer.)
  </para>

  <para>
   Alternatively, you can run individual test suites by typing
   <literal>make check</literal> or