<literal>kerberos</literal>, additional tests that require
       an MIT Kerberos installation are enabled.
      </para>
     </listitem>
    </varlistentry>

    <varlistentry>
     <term><literal>wal_consistency_checking</literal></term>
     <listitem>
      <para>
       Uses <literal>wal_consistency_checking=all</literal> while running
       certain tests under <filename>src/test/recovery</filename>.  Not
       enabled by default because it is resource intensive.
      </para>
     </listitem>
    </varlistentry>

    <varlistentry>
     <term><literal>xid_wraparound</literal></term>
     <listitem>
      <para>
       Runs the test suite under <filename>src/test/modules/xid_wraparound</filename>.
       Not enabled by default because it is resource intensive.
      </para>
     </listitem>
    </varlistentry>

    <varlistentry>
     <term><literal>oauth</literal></term>
     <listitem>
      <para>
       Runs the test suite under <filename>src/test/modules/oauth_validator</filename>.
       This opens TCP/IP listen sockets for a test server running HTTPS.
      </para>
     </listitem>
    </varlistentry>
   </variablelist>

   Tests for features that are not supported by the current build
   configuration are not run even if they are mentioned in
   <varname>PG_TEST_EXTRA</varname>.
  </para>

  <para>
   In addition, there are tests in <filename>src/test/modules</filename>
   which will be run by <literal>make check-world</literal> but not
   by <literal>make installcheck-world</literal>.  This is because they
   install non-production extensions or have other side-effects that are
   considered undesirable for a production installation.  You can
   use <literal>make install</literal> and <literal>make
   installcheck</literal> in one of those subdirectories if you wish,
   but it's not recommended to do so with a non-test server.
  </para>
  </sect2>

  <sect2 id="regress-run-locale">
   <title>Locale and Encoding</title>

   <para>
    By default, tests using a temporary installation use the
    locale defined in the current environment and the corresponding
    database encoding as determined by <command>initdb</command>.  It
    can be useful to test different locales by setting the appropriate
    environment variables, for example:
<screen>
make check LANG=C
make check LC_COLLATE=en_US.utf8 LC_CTYPE=fr_CA.utf8
</screen>
    For implementation reasons, setting <envar>LC_ALL</envar> does not
    work for this purpose; all the other locale-related environment
    variables do work.
   </para>

   <para>
    When testing against an existing installation, the locale is
    determined by the existing database cluster and cannot be set
    separately for the test run.
   </para>

   <para>
    You can also choose the database encoding explicitly by setting
    the variable <envar>ENCODING</envar>, for example:
<screen>
make check LANG=C ENCODING=EUC_JP
</screen>
    Setting the database encoding this way typically only makes sense
    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