We will probably not set up a
      web server to reproduce your problem. In any case remember to provide
      the exact input files; do not guess that the problem happens for
      <quote>large files</quote> or <quote>midsize databases</quote>, etc. since this
      information is too inexact to be of use.
     </para>
    </listitem>

    <listitem>
     <para>
      The output you got. Please do not say that it <quote>didn't work</quote> or
      <quote>crashed</quote>. If there is an error message,
      show it, even if you do not understand it. If the program terminates with
      an operating system error, say which. If nothing at all happens, say so.
      Even if the result of your test case is a program crash or otherwise obvious
      it might not happen on our platform. The easiest thing is to copy the output
      from the terminal, if possible.
     </para>
     <note>
      <para>
       If you are reporting an error message, please obtain the most verbose
       form of the message.  In <application>psql</application>, say <literal>\set
       VERBOSITY verbose</literal> beforehand.  If you are extracting the message
       from the server log, set the run-time parameter
       <xref linkend="guc-log-error-verbosity"/> to <literal>verbose</literal> so that all
       details are logged.
      </para>
     </note>
     <note>
      <para>
       In case of fatal errors, the error message reported by the client might
       not contain all the information available. Please also look at the
       log output of the database server. If you do not keep your server's log
       output, this would be a good time to start doing so.
      </para>
     </note>
    </listitem>

    <listitem>
     <para>
      The output you expected is very important to state. If you just write
      <quote>This command gives me that output.</quote> or <quote>This is not
      what I expected.</quote>, we might run it ourselves, scan the output, and
      think it looks OK and is exactly what we expected. We should not have to
      spend the time to decode the exact semantics behind your commands.
      Especially refrain from merely saying that <quote>This is not what SQL says/Oracle
      does.</quote> Digging out the correct behavior from <acronym>SQL</acronym>
      is not a fun undertaking, nor do we all know how all the other relational
      databases out there behave. (If your problem is a program crash, you can
      obviously omit this item.)
     </para>
    </listitem>

    <listitem>
     <para>
      Any command line options and other start-up options, including
      any relevant environment variables or configuration files that
      you changed from the default. Again, please provide exact
      information. If you are using a prepackaged distribution that
      starts the database server at boot time, you should try to find
      out how that is done.
     </para>
    </listitem>

    <listitem>
     <para>
      Anything you did at all differently from the installation
      instructions.
     </para>
    </listitem>

    <listitem>
     <para>
      The <productname>PostgreSQL</productname> version. You can run the command
      <literal>SELECT version();</literal> to
      find out the version of the server you are connected to.  Most executable
      programs also support a <option>--version</option> option; at least
      <literal>postgres --version</literal> and <literal>psql --version</literal>
      should work.
      If the function or the options do not exist then your version is
      more than old enough to warrant an upgrade.
      If you run a prepackaged version, such as RPMs, say so, including any
      subversion the package might have. If you are talking about a Git
      snapshot, mention that, including the commit hash.
     </para>

     <para>
      If your version is older than &version; we will almost certainly
      tell you to upgrade. There are many bug fixes and improvements
      in each new