Correct erroneous explanation of DEADLOCK_TIMEOUT configuration setting.

diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgml
index addfc54456889a8a00b474352bd8020028fdeb9d..78978fdb35c70ae770e53bf2b39fc21bc0ef6be6 100644 (file)
--- a/doc/src/sgml/runtime.sgml
+++ b/doc/src/sgml/runtime.sgml
@@ -1,5 +1,5 @@
 <!--
-$Header: /cvsroot/pgsql/doc/src/sgml/runtime.sgml,v 1.15 2000/07/16 14:47:57 petere Exp $
+$Header: /cvsroot/pgsql/doc/src/sgml/runtime.sgml,v 1.16 2000/07/17 22:32:44 tgl Exp $
 -->
 
 <Chapter Id="runtime">
@@ -374,8 +374,8 @@ Is the postmaster running at 'localhost' and accepting connections on Unix socke
    <para>
     One way to set these options is to create a file
     <filename>postgresql.conf</filename> in the data directory (e.g.,
-    <filename>/usr/local/pgsql/data</filename>). An example of how
-    this file could look like is this:
+    <filename>/usr/local/pgsql/data</filename>). An example of what
+    this file could look like is:
 <programlisting>
 # This is a comment
 log_connections = yes
@@ -829,15 +829,22 @@ env PGOPTIONS='--geqo=off' psql
       <term>DEADLOCK_TIMEOUT (<type>integer</type>)</term>
       <listitem>
        <para>
-        <productname>Postgres</productname> assumes that if
-        transactions are stuck for this many milliseconds then a
-        deadlock has occurred. Although it is technically possible to
-        detect deadlocks <quote>properly</quote>, the present
-        optimistic approach is much more efficient in practice. If you get
-        too many deadlock detected messages when you provably did not
-        have one, you might want to try raising this value. The
-        default is 1000 (i.e., one second). This option can only be
-        set at server start.
+        This is the amount of time, in milliseconds, to wait on a lock
+       before checking to see if there is a deadlock condition or not.
+       The check for deadlock is relatively slow, so we don't want to
+       run it every time we wait for a lock.  We (optimistically?)
+       assume that deadlocks are not common in production applications,
+       and just wait on the lock for awhile before starting to ask
+       questions about whether it can ever get unlocked.
+       Increasing this value reduces the amount of time wasted in
+       needless deadlock checks, but slows down reporting of real deadlock
+       errors.  The default is 1000 (i.e., one second), which is probably
+       about the smallest value you would want in practice.  On a heavily
+       loaded server you might want to raise it.  Ideally the setting
+       should exceed your typical transaction time, so as to improve the
+       odds that the lock will be released before the waiter decides to
+       check for deadlock. 
+       This option can only be set at server start.
        </para>
       </listitem>
      </varlistentry>
@@ -889,7 +896,8 @@ env PGOPTIONS='--geqo=off' psql
        <para>
         Determines how many concurrent connections the database server
         will allow. The default is 32. There is also a compiled-in
-        hard upper limit on this option, which is currently 1024. This
+        hard upper limit on this value, which is typically 1024
+       (both numbers can be altered when compiling the server). This
         parameter can only be set at server start.
        </para>
       </listitem>