<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 <literal>make installcheck</literal> in the appropriate
   subdirectory of the build tree.  Keep in mind that <literal>make
   installcheck</literal> assumes you've installed the relevant module(s), not
   only the core server.
  </para>

  <para>
   The additional tests that can be invoked this way include:
  </para>

  <itemizedlist>
   <listitem>
    <para>
     Regression tests for optional procedural languages.
     These are located under <filename>src/pl</filename>.
    </para>
   </listitem>
   <listitem>
    <para>
     Regression tests for <filename>contrib</filename> modules,
     located under <filename>contrib</filename>.
     Not all <filename>contrib</filename> modules have tests.
    </para>
   </listitem>
   <listitem>
    <para>
     Regression tests for the interface libraries,
     located in <filename>src/interfaces/libpq/test</filename> and
     <filename>src/interfaces/ecpg/test</filename>.
    </para>
   </listitem>
   <listitem>
    <para>
     Tests for core-supported authentication methods,
     located in <filename>src/test/authentication</filename>.
     (See below for additional authentication-related tests.)
    </para>
   </listitem>
   <listitem>
    <para>
     Tests stressing behavior of concurrent sessions,
     located in <filename>src/test/isolation</filename>.
    </para>
   </listitem>
   <listitem>
    <para>
     Tests for crash recovery and physical replication,
     located in <filename>src/test/recovery</filename>.
    </para>
   </listitem>
   <listitem>
    <para>
     Tests for logical replication,
     located in <filename>src/test/subscription</filename>.
    </para>
   </listitem>
   <listitem>
    <para>
     Tests of client programs, located under <filename>src/bin</filename>.
    </para>
   </listitem>
  </itemizedlist>

  <para>
   When using <literal>installcheck</literal> mode, these tests will create
   and destroy test databases whose names
   include <literal>regression</literal>, for
   example <literal>pl_regression</literal>
   or <literal>contrib_regression</literal>.  Beware of
   using <literal>installcheck</literal> mode with an installation that has
   any non-test databases named that way.
  </para>

  <para>
   Some of these auxiliary test suites use the TAP infrastructure explained
   in <xref linkend="regress-tap"/>.
   The TAP-based tests are run only when PostgreSQL was configured with the
   option <option>--enable-tap-tests</option>.  This is recommended for
   development, but can be omitted if there is no suitable Perl installation.
  </para>

  <para>
   Some test suites are not run by default, either because they are not secure
   to run on a multiuser system, because they require special software or
   because they are resource intensive.  You can decide which test suites to
   run additionally by setting the <command>make</command> or environment
   variable <varname>PG_TEST_EXTRA</varname> to a whitespace-separated list,
   for example:
<programlisting>
make check-world