1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
|
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>17.11.Lock Management</title>
<link rel="stylesheet" href="stylesheet.css" type="text/css">
<link rev="made" href="pgsql-docs@postgresql.org">
<meta name="generator" content="DocBook XSL Stylesheets V1.70.0">
<link rel="start" href="index.html" title="PostgreSQL 8.1.4 Documentation">
<link rel="up" href="runtime-config.html" title="Chapter17.Server Configuration">
<link rel="prev" href="runtime-config-client.html" title="17.10.Client Connection Defaults">
<link rel="next" href="runtime-config-compatible.html" title="17.12.Version and Platform Compatibility">
<link rel="copyright" href="ln-legalnotice.html" title="Legal Notice">
</head>
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="sect1" lang="en">
<div class="titlepage"><div><div><h2 class="title" style="clear: both">
<a name="runtime-config-locks"></a>17.11.Lock Management</h2></div></div></div>
<div class="variablelist"><dl>
<dt>
<a name="guc-deadlock-timeout"></a><span class="term"><code class="varname">deadlock_timeout</code> (<code class="type">integer</code>)</span>
</dt>
<dd><p> This is the amount of time, in milliseconds, to wait on a lock
before checking to see if there is a deadlock condition. The
check for deadlock is relatively slow, so the server doesn't run
it every time it waits for a lock. We (optimistically?) assume
that deadlocks are not common in production applications and
just wait on the lock for a while before starting the check for a
deadlock. 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 a lock will be released before
the waiter decides to check for deadlock.
</p></dd>
<dt>
<a name="guc-max-locks-per-transaction"></a><span class="term"><code class="varname">max_locks_per_transaction</code> (<code class="type">integer</code>)</span>
</dt>
<dd>
<p> The shared lock table is created with room to describe locks on
<code class="varname">max_locks_per_transaction</code> *
(<a href="runtime-config-connection.html#guc-max-connections">max_connections</a> +
<a href="runtime-config-resource.html#guc-max-prepared-transactions">max_prepared_transactions</a>) objects;
hence, no more than this many distinct objects can
be locked at any one time. (Thus, this parameter's name may be
confusing: it is not a hard limit on the number of locks taken
by any one transaction, but rather a maximum average value.)
The default, 64, has historically
proven sufficient, but you might need to raise this value if you
have clients that touch many different tables in a single
transaction. This option can only be set at server start.
</p>
<p> Increasing this parameter may cause <span class="productname">PostgreSQL</span>
to request more <span class="systemitem">System V</span> shared
memory than your operating system's default configuration
allows. See <a href="kernel-resources.html#sysvipc" title="16.4.1.Shared Memory and Semaphores">Section16.4.1, “Shared Memory and Semaphores”</a> for information on how to
adjust those parameters, if necessary.
</p>
</dd>
</dl></div>
</div></body>
</html>
|
