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 release, so it is quite possible that a bug you have
      encountered in an older release of <productname>PostgreSQL</productname>
      has already been fixed. We can only provide limited support for
      sites using older releases of <productname>PostgreSQL</productname>; if you
      require more than we can provide, consider acquiring a
      commercial support contract.
     </para>
     <para>
     </para>
    </listitem>

    <listitem>
     <para>
      Platform information. This includes the kernel name and version,
      C library, processor, memory information, and so on. In most
      cases it is sufficient to report the vendor and version, but do
      not assume everyone knows what exactly <quote>Debian</quote>
      contains or that everyone runs on x86_64. If you have
      installation problems then information about the toolchain on
      your machine (compiler, <application>make</application>, and so
      on) is also necessary.
     </para>
    </listitem>
   </itemizedlist>

   Do not be afraid if your bug report becomes rather lengthy. That is a fact of life.
   It is better to report everything the first time than us having to squeeze the
   facts out of you. On the other hand, if your input files are huge, it is
   fair to ask first whether somebody is interested in looking into it.  Here is
   an <ulink url="https://www.chiark.greenend.org.uk/~sgtatham/bugs.html">article</ulink>
   that outlines some more tips on reporting bugs.
  </para>

  <para>
   Do not spend all your time to figure out which changes in the input make
   the problem go away. This will probably not help solving it. If it turns
   out that the bug cannot be fixed right away, you will still have time to
   find and share your work-around. Also, once again, do not waste your time
   guessing why the bug exists. We will find that out soon enough.
  </para>

  <para>
   When writing a bug report, please avoid confusing terminology.
   The software package in total is called <quote>PostgreSQL</quote>,
   sometimes <quote>Postgres</quote> for short. If you
   are specifically talking about the backend process, mention that, do not
   just say <quote>PostgreSQL crashes</quote>.