From d0ca92cb530ad1e6d6aa64b0d9712a3feb6a294c Mon Sep 17 00:00:00 2001
From: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 17 Jul 2000 22:32:44 +0000
Subject: [PATCH] Correct erroneous explanation of DEADLOCK_TIMEOUT
configuration setting.
---
doc/src/sgml/runtime.sgml | 34 +++++++++++++++++++++-------------
1 file changed, 21 insertions(+), 13 deletions(-)
diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgml
index addfc544568..78978fdb35c 100644
--- 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>
--
GitLab