Received: from maia.hub.org (maia-2.hub.org [200.46.204.251])
	by mail.postgresql.org (Postfix) with ESMTP id 439261337D5A
	for <pgsql-performance-postgresql.org@mail.postgresql.org>;
	Wed, 15 Sep 2010 21:32:46 -0300 (ADT)
Received: from mail.postgresql.org ([200.46.204.86])
	by maia.hub.org (mx1.hub.org [200.46.204.251]) (amavisd-maia,
	port 10024) with ESMTP id 73582-09
	for <pgsql-performance-postgresql.org@mail.postgresql.org>;
	Thu, 16 Sep 2010 00:32:39 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from moutng.kundenserver.de (moutng.kundenserver.de
	[212.227.126.187])
	by mail.postgresql.org (Postfix) with ESMTP id 7FF0B1337C36
	for <pgsql-performance@postgresql.org>;
	Wed, 15 Sep 2010 21:32:38 -0300 (ADT)
Received: from [192.168.1.6] (static-71-179-240-8.bltmmd.fios.verizon.net
	[71.179.240.8])
	by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis)
	id 0Lmyme-1OLtm92XXg-00h4yO; Thu, 16 Sep 2010 02:32:34 +0200
Message-ID: <4C9165A0.4060003@2ndquadrant.com>
Date: Wed, 15 Sep 2010 20:32:32 -0400
From: Greg Smith <greg@2ndquadrant.com>
User-Agent: Thunderbird 2.0.0.24 (X11/20100317)
MIME-Version: 1.0
To: Tobias Brox <tobixen@gmail.com>
CC: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-performance@postgresql.org
Subject: Re: locking issue on simple selects?
References: <AANLkTikh++7mouBb7cr2C9zMPKtRffVxDK0QFTf16HLo@mail.gmail.com>
	<4096.1284557987@sss.pgh.pa.us>
	<AANLkTikzssP3AKeQhM+tB_8tScRGs2iGSqTJJUg2w3DP@mail.gmail.com>
	<4C911E58.6030605@2ndquadrant.com>
	<AANLkTim+WH6xXj-P7KVm7gx-7OnB0EEffuumWZ16=UFH@mail.gmail.com>
In-Reply-To: <AANLkTim+WH6xXj-P7KVm7gx-7OnB0EEffuumWZ16=UFH@mail.gmail.com>
Content-Type: multipart/alternative;
	boundary="------------020406000408080108040504"
X-Provags-ID: V02:K0:rTwnK/lijLDAxgbEqHz9YWKEnJh8G00e3pU1u82HyHi
	ny+0CThIiwOQgU2h4WDopTZuLt1jIG9En3I5VufpYDqDA5bKHh
	/A3pnCMTKdSEN6wm8DKnmNOvBdDe26PbX/J4hnjAhttipIsGY3
	ALN9RA/lXoI4lTnj8OeMYUY7U+evlmMECNvldY+PUBw438qNcO
	U9Kil2Kr5JgiPFUDJRIGOcAS257g9GHlb16FhF1mr4=
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=-1.899 tagged_above=-10 required=5
	tests=BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001
X-Spam-Level: 
X-Archive-Number: 201009/98
X-Sequence-Number: 40301

This is a multi-part message in MIME format.
--------------020406000408080108040504
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Tobias Brox wrote:
> I think those pages probably should be merged ... hmm ... if
> I manage to solve my locking issues I should probably try and
> contribute to the wiki.
>   

Certainly the 3rd one could be merged with one of the other two, and 
maybe all merged into one.  I haven't cleaned up that whole area in a 
whole, it's due for a round of it soon. You're welcome to take a shot at 
it.  We can always revert any mistakes made.

>> reducing deadlock_timeout.
>>     
>
> It's set to one second, and some of the jams we have been experiencing
> has lasted for several minutes.  I also think it should say in the pg
> log if there is a deadlock situation?  

deadlock_timeout is how long a process trying to acquire a lock waits 
before it a) looks for a deadlock, and b) prints a report that it's 
waiting into the logs when log_lock_waits is on.  So if you're looking 
for slow lock acquisition that's in the sub-second range, it can be 
useful to reduce regardless of whether deadlock ever happens.  That 
doesn't sound like your situation though.

-- 
Greg Smith, 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD
PostgreSQL Training, Services and Support  www.2ndQuadrant.us
Author, "PostgreSQL 9.0 High Performance"    Pre-ordering at:
https://www.packtpub.com/postgresql-9-0-high-performance/book


--------------020406000408080108040504
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Tobias Brox wrote:<br>
<blockquote
 cite="mid:AANLkTim+WH6xXj-P7KVm7gx-7OnB0EEffuumWZ16=UFH@mail.gmail.com"
 type="cite">
  <pre wrap="">I think those pages probably should be merged ... hmm ... if
I manage to solve my locking issues I should probably try and
contribute to the wiki.
  </pre>
</blockquote>
<br>
Certainly the 3rd one could be merged with one of the other two, and
maybe all merged into one.&nbsp; I haven't cleaned up that whole area in a
whole, it's due for a round of it soon. You're welcome to take a shot
at it.&nbsp; We can always revert any mistakes made.<br>
<br>
<blockquote
 cite="mid:AANLkTim+WH6xXj-P7KVm7gx-7OnB0EEffuumWZ16=UFH@mail.gmail.com"
 type="cite">
  <blockquote type="cite">
    <pre wrap="">reducing deadlock_timeout.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
It's set to one second, and some of the jams we have been experiencing
has lasted for several minutes.  I also think it should say in the pg
log if there is a deadlock situation?  </pre>
</blockquote>
<br>
deadlock_timeout is how long a process trying to acquire a lock waits
before it a) looks for a deadlock, and b) prints a report that it's
waiting into the logs when log_lock_waits is on.&nbsp; So if you're looking
for slow lock acquisition that's in the sub-second range, it can be
useful to reduce regardless of whether deadlock ever happens.&nbsp; That
doesn't sound like your situation though.<br>
<br>
<pre class="moz-signature" cols="72">-- 
Greg Smith, 2ndQuadrant US <a class="moz-txt-link-abbreviated" href="mailto:greg@2ndQuadrant.com">greg@2ndQuadrant.com</a> Baltimore, MD
PostgreSQL Training, Services and Support  <a class="moz-txt-link-abbreviated" href="http://www.2ndQuadrant.us">www.2ndQuadrant.us</a>
Author, "PostgreSQL 9.0 High Performance"    Pre-ordering at:
<a class="moz-txt-link-freetext" href="https://www.packtpub.com/postgresql-9-0-high-performance/book">https://www.packtpub.com/postgresql-9-0-high-performance/book</a>
</pre>
</body>
</html>

--------------020406000408080108040504--