if the locale is C; otherwise the encoding is chosen automatically
    from the locale, and specifying an encoding that does not match
    the locale will result in an error.
   </para>

   <para>
    The database encoding can be set for tests against either a temporary or
    an existing installation, though in the latter case it must be
    compatible with the installation's locale.
   </para>
  </sect2>

  <sect2 id="regress-run-custom-settings">
   <title>Custom Server Settings</title>

   <para>
    There are several ways to use custom server settings when running a test
    suite.  This can be useful to enable additional logging, adjust resource
    limits, or enable extra run-time checks such as <xref
    linkend="guc-debug-discard-caches"/>.  But note that not all tests can be
    expected to pass cleanly with arbitrary settings.
   </para>

   <para>
    Extra options can be passed to the various <command>initdb</command>
    commands that are run internally during test setup using the environment
    variable <envar>PG_TEST_INITDB_EXTRA_OPTS</envar>.  For example, to run a
    test with checksums enabled and a custom WAL segment size and
    <varname>work_mem</varname> setting, use:
<screen>
make check PG_TEST_INITDB_EXTRA_OPTS='-k --wal-segsize=4 -c work_mem=50MB'
</screen>
   </para>

   <para>
    For the core regression test suite and other tests driven by
    <command>pg_regress</command>, custom run-time server settings can also be
    set in the <varname>PGOPTIONS</varname> environment variable (for settings
    that allow this), for example:
<screen>
make check PGOPTIONS="-c debug_parallel_query=regress -c work_mem=50MB"
</screen>
    (This makes use of functionality provided by libpq; see <xref
    linkend="libpq-connect-options"/> for details.)
   </para>

   <para>
    When running against a temporary installation, custom settings can also be
    set by supplying a pre-written <filename>postgresql.conf</filename>:
<screen>
echo 'log_checkpoints = on' > test_postgresql.conf
echo 'work_mem = 50MB' >> test_postgresql.conf
make check EXTRA_REGRESS_OPTS="--temp-config=test_postgresql.conf"
</screen>
   </para>

  </sect2>

  <sect2 id="regress-run-extra-tests">
   <title>Extra Tests</title>

   <para>
    The core regression test suite contains a few test files that are not
    run by default, because they might be platform-dependent or take a
    very long time to run.  You can run these or other extra test
    files by setting the variable <envar>EXTRA_TESTS</envar>.  For
    example, to run the <literal>numeric_big</literal> test:
<screen>
make check EXTRA_TESTS=numeric_big
</screen>
   </para>
  </sect2>
  </sect1>

  <sect1 id="regress-evaluation">
   <title>Test Evaluation</title>

   <para>
    Some properly installed and fully functional
    <productname>PostgreSQL</productname> installations can
    <quote>fail</quote> some of these regression tests due to
    platform-specific artifacts such as varying floating-point representation
    and message wording. The tests are currently evaluated using a simple
    <command>diff</command> comparison against the outputs
    generated on a reference system, so the results are sensitive to
    small system differences.  When a test is reported as
    <quote>failed</quote>, always examine the differences between
    expected and actual results; you might find that the
    differences are not significant.  Nonetheless, we still strive to
    maintain accurate reference files across all supported platforms,
    so it can be expected that all tests pass.
   </para>

   <para>
    The actual outputs of the regression tests are in files in the
    <filename>src/test/regress/results</filename> directory. The test
    script uses <command>diff</command> to compare each output
    file against the reference outputs stored in the
    <filename>src/test/regress/expected</filename> directory.  Any
    differences are saved for your inspection in
    <filename>src/test/regress/regression.diffs</filename>.