mirror/postgresql
2
0
Fork 0
mirror of https://git.postgresql.org/git/postgresql.git synced 2024-11-27 07:21:09 +08:00
Code Issues Packages Projects Releases Wiki Activity

Correct erroneous explanation of DEADLOCK_TIMEOUT configuration setting.

Browse Source
This commit is contained in:
Tom Lane 2000-07-17 22:32:44 +00:00
parent 44eaafe3f8
commit d0ca92cb53
1 changed files with 21 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

34
doc/src/sgml/runtime.sgml
View File

@ -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>