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 @@
 
 
 
@@ -374,8 +374,8 @@ Is the postmaster running at 'localhost' and accepting connections on Unix socke
    
     One way to set these options is to create a file
     postgresql.conf in the data directory (e.g.,
-    /usr/local/pgsql/data). An example of how
-    this file could look like is this:
+    /usr/local/pgsql/data). An example of what
+    this file could look like is:
 
 # This is a comment
 log_connections = yes
@@ -829,15 +829,22 @@ env PGOPTIONS='--geqo=off' psql
       DEADLOCK_TIMEOUT (integer)
       
        
-        Postgres assumes that if
-        transactions are stuck for this many milliseconds then a
-        deadlock has occurred. Although it is technically possible to
-        detect deadlocks properly, 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.
        
       
      
@@ -889,7 +896,8 @@ env PGOPTIONS='--geqo=off' psql
        
         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.