problems.sgml

PostgreSQL 8.1.4的源码 适用于Linux下的开源数据库系统

      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>postmaster --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 may have. If you are talking about a CVS
      snapshot, mention that, including its date and time.
     </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</>
      has already been fixed. We can only provide limited support for
      sites using older releases of <productname>PostgreSQL</>; 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 Pentiums. 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="http://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 server, mention that, do not
   just say <quote>PostgreSQL crashes</quote>.  A crash of a single
   backend server process is quite different from crash of the parent
   <quote>postmaster</> process; please don't say <quote>the postmaster
   crashed</> when you mean a single backend process went down, nor vice versa.
   Also, client programs such as the interactive frontend <quote><application>psql</application></quote>
   are completely separate from the backend.  Please try to be specific
   about whether the problem is on the client or server side.
  </para>
 </sect2>

 <sect2>
  <title>Where to report bugs</title>

  <para>
   In general, send bug reports to the bug report mailing list at
   <email>[e-mail]</email>.
   You are requested to use a descriptive subject for your email
   message, perhaps parts of the error message.
  </para>

  <para> 
   Another method is to fill in the bug report web-form available
   at the project's
   <ulink url="http://www.postgresql.org/">web site</ulink>.
   Entering a bug report this way causes it to be mailed to the
   <email>[e-mail]</email> mailing list.
  </para>

  <para>
   If your bug report has security implications and you'd prefer that it
   not become immediately visible in public archives, don't send it to
   <literal>pgsql-bugs</literal>.  Security issues can be
   reported privately to <email>[e-mail]</email>.
  </para>

  <para> 
   Do not send bug reports to any of the user mailing lists, such as
   <email>[e-mail]</email> or
   <email>[e-mail]</email>.
   These mailing lists are for answering
   user questions, and their subscribers normally do not wish to receive
   bug reports. More importantly, they are unlikely to fix them.
  </para>

  <para>
   Also, please do <emphasis>not</emphasis> send reports to
   the developers' mailing list <email>[e-mail]</email>.
   This list is for discussing the
   development of <productname>PostgreSQL</productname>, and it would be nice
   if we could keep the bug reports separate. We might choose to take up a
   discussion about your bug report on <literal>pgsql-hackers</literal>,
   if the problem needs more review.
  </para>

  <para>
   If you have a problem with the documentation, the best place to report it
   is the documentation mailing list <email>[e-mail]</email>.
   Please be specific about what part of the documentation you are unhappy
   with.
  </para>
 
  <para>
   If your bug is a portability problem on a non-supported platform,
   send mail to <email>[e-mail]</email>,
   so we (and you) can work on
   porting <productname>PostgreSQL</productname> to your platform.
  </para>

  <note>
   <para>
    Due to the unfortunate amount of spam going around, all of the above
    email addresses are closed mailing lists. That is, you need to be
    subscribed to a list to be allowed to post on it.  (You need not be
    subscribed to use the bug-report web form, however.)
    If you would like to send mail but do not want to receive list traffic,
    you can subscribe and set your subscription option to <literal>nomail</>.
    For more information send mail to
    <email>[e-mail]</email>
    with the single word <literal>help</> in the body of the message.
   </para>
  </note>
 </sect2>
</sect1>

<!-- Keep this comment at the end of the file
Local variables:
mode:sgml
sgml-omittag:nil
sgml-shorttag:t
sgml-minimize-attributes:nil
sgml-always-quote-attributes:t
sgml-indent-step:1
sgml-indent-data:t
sgml-parent-document:nil
sgml-default-dtd-file:"./reference.ced"
sgml-exposed-tags:nil
sgml-local-catalogs:("/usr/lib/sgml/catalog")
sgml-local-ecat-files:nil
End:
-->