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 environment variable
    <varname>PG_TEST_TIMEOUT_DEFAULT</varname> to a higher number will change
    the default to avoid this.
   </para>
  </sect2>

  </sect1>

  <sect1 id="regress-coverage">
   <title>Test Coverage Examination</title>

   <para>
    The PostgreSQL source code can be compiled with coverage testing
    instrumentation, so that it becomes possible to examine which
    parts of the code are covered by the regression tests or any other
    test suite that is run with the code.  This is currently supported
    when compiling with GCC, and it requires the <literal>gcov</literal>
    and <literal>lcov</literal> packages.
   </para>

   <sect2 id="regress-coverage-configure">
    <title>Coverage with Autoconf and Make</title>
    <para>
     A typical workflow looks like this:
<screen>
./configure --enable-coverage ... OTHER OPTIONS ...
make
make check # or other test suite
make coverage-html
</screen>
     Then point your HTML browser
     to <filename>coverage/index.html</filename>.
    </para>

    <para>
     If you don't have <command>lcov</command> or prefer text output over an
     HTML report, you can run
<screen>
make coverage
</screen>
     instead of <literal>make coverage-html</literal>, which will
     produce <filename>.gcov</filename> output files for each source file
     relevant to the test.  (<literal>make coverage</literal> and <literal>make
     coverage-html</literal> will overwrite each other's files, so mixing them
     might be confusing.)
    </para>

    <para>
     You can run several different tests before making the coverage report;
     the execution counts will accumulate.  If you want
     to reset the execution counts between test runs, run:
<screen>
make coverage-clean
</screen>
    </para>

    <para>
     You can run the <literal>make coverage-html</literal> or <literal>make
     coverage</literal> command in a subdirectory if you want a coverage
     report for only a portion of the code tree.
    </para>

    <para>
     Use <literal>make distclean</literal> to clean up when done.
    </para>
   </sect2>

   <sect2 id="regress-coverage-meson">
    <title>Coverage with Meson</title>
    <para>
     A typical workflow looks like this:
<screen>
meson setup -Db_coverage=true ... OTHER OPTIONS ... builddir/
meson compile -C builddir/
meson test -C builddir/
cd builddir/
ninja coverage-html
</screen>
     Then point your HTML browser
     to <filename>./meson-logs/coveragereport/index.html</filename>.
    </para>

    <para>
     You can run several different tests before making the coverage report;
     the execution counts will accumulate.
    </para>
   </sect2>
  </sect1>

</chapter>