information.
   </para>

   <para>
    The <command>make</command> variable <varname>PROVE_TESTS</varname>
    can be used to define a whitespace-separated list of paths relative
    to the <filename>Makefile</filename> invoking <command>prove</command>
    to run the specified subset of tests instead of the default
    <filename>t/*.pl</filename>.  For example:
<programlisting>
make check PROVE_TESTS='t/001_test1.pl t/003_test3.pl'
</programlisting>
   </para>

   <para>
    The TAP tests require the Perl module <literal>IPC::Run</literal>.
    This module is available from
    <ulink url="https://metacpan.org/dist/IPC-Run">CPAN</ulink>
    or an operating system package.
    They also require <productname>PostgreSQL</productname> to be
    configured with the option <option>--enable-tap-tests</option>.
   </para>

   <para>
    Generically speaking, the TAP tests will test the executables in a
    previously-installed installation tree if you say <literal>make
    installcheck</literal>, or will build a new local installation tree from
    current sources if you say <literal>make check</literal>.  In either
    case they will initialize a local instance (data directory) and
    transiently run a server in it.  Some of these tests run more than one
    server.  Thus, these tests can be fairly resource-intensive.
   </para>

   <para>
    It's important to realize that the TAP tests will start test server(s)
    even when you say <literal>make installcheck</literal>; this is unlike
    the traditional non-TAP testing infrastructure, which expects to use an
    already-running test server in that case.  Some PostgreSQL
    subdirectories contain both traditional-style and TAP-style tests,
    meaning that <literal>make installcheck</literal> will produce a mix of
    results from temporary servers and the already-running test server.
   </para>

  <sect2 id="regress-tap-vars">
   <title>Environment Variables</title>

   <para>
    Data directories are named according to the test filename, and will be
    retained if a test fails.  If the environment variable
    <varname>PG_TEST_NOCLEAN</varname> is set, data directories will be
    retained regardless of test status.  For example, retaining the data
    directory regardless of test results when running the
    <application>pg_dump</application> tests:
<programlisting>
PG_TEST_NOCLEAN=1 make -C src/bin/pg_dump check
</programlisting>
    This environment variable also prevents the test's temporary directories
    from being removed.
   </para>

   <para>
    Many operations in the test suites use a 180-second timeout, which on slow
    hosts may lead to load-induced timeouts.  Setting the