<productname>PostgreSQL</productname>
     code.
    </para>
   </sect2>

   <sect2 id="regress-evaluation-ordering-differences">
    <title>Row Ordering Differences</title>

    <para>
You might see differences in which the same rows are output in a
different order than what appears in the expected file.  In most cases
this is not, strictly speaking, a bug.  Most of the regression test
scripts are not so pedantic as to use an <literal>ORDER BY</literal> for every single
<literal>SELECT</literal>, and so their result row orderings are not well-defined
according to the SQL specification.  In practice, since we are
looking at the same queries being executed on the same data by the same
software, we usually get the same result ordering on all platforms,
so the lack of <literal>ORDER BY</literal> is not a problem.  Some queries do exhibit
cross-platform ordering differences, however.  When testing against an
already-installed server, ordering differences can also be caused by
non-C locale settings or non-default parameter settings, such as custom values
of <varname>work_mem</varname> or the planner cost parameters.
    </para>

    <para>
Therefore, if you see an ordering difference, it's not something to
worry about, unless the query does have an <literal>ORDER BY</literal> that your
result is violating.  However, please report it anyway, so that we can add an
<literal>ORDER BY</literal> to that particular query to eliminate the bogus
<quote>failure</quote> in future releases.
    </para>

    <para>
You might wonder why we don't order all the regression test queries explicitly
to get rid of this issue once and for all.  The reason is that that would
make the regression tests less useful, not more, since they'd tend
to exercise query plan types that produce ordered results to the
exclusion of those that don't.
    </para>
   </sect2>

   <sect2 id="regress-evaluation-stack-depth">
    <title>Insufficient Stack Depth</title>

    <para>
     If the <literal>errors</literal> test results in a server crash
     at the <literal>select infinite_recurse()</literal> command, it means that
     the platform's limit on process stack size is smaller than the
     <xref linkend="guc-max-stack-depth"/> parameter indicates.  This
     can be fixed by running the server under a higher stack
     size limit (4MB is recommended with the default value of
     <varname>max_stack_depth</varname>).  If you are unable to do that, an
     alternative is to reduce the value of <varname>max_stack_depth</varname>.
    </para>

    <para>
     On platforms supporting <function>getrlimit()</function>, the server should
     automatically choose a safe value of <varname>max_stack_depth</varname>;
     so unless you've manually overridden this setting, a failure of this
     kind is a reportable bug.
    </para>
   </sect2>

   <sect2 id="regress-evaluation-random-test">
    <title>The <quote>random</quote> Test</title>

    <para>
     The <literal>random</literal> test script is intended to produce
     random results.   In very rare cases, this causes that regression
     test to fail.  Typing:
<programlisting>
diff results/random.out expected/random.out
</programlisting>
     should produce only one or a few lines of differences.  You need
     not worry unless the random test fails repeatedly.
    </para>
   </sect2>

   <sect2 id="regress-evaluation-config-params">
    <title>Configuration Parameters</title>

    <para>
     When running the tests against an existing installation, some non-default
     parameter settings could cause the tests to fail.  For example, changing
     parameters such as <varname>enable_seqscan</varname> or
     <varname>enable_indexscan</varname> could cause plan changes that would
     affect the results of tests that use <command>EXPLAIN</command>.
    </para>
   </sect2>
  </sect1>

<!-- We might want to move the following section into the developer's guide. -->
  <sect1 id="regress-variant">
   <title>Variant Comparison