Received: from localhost (unknown [200.46.204.183]) by developer.postgresql.org (Postfix) with ESMTP id 0BA092E004E for ; Tue, 13 May 2008 21:52:21 -0300 (ADT) Received: from developer.postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 74335-03-7 for ; Tue, 13 May 2008 21:52:07 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from lists.commandprompt.com (host-159.commandprompt.net [207.173.203.159]) by developer.postgresql.org (Postfix) with ESMTP id C17E32E00BF for ; Tue, 13 May 2008 21:49:39 -0300 (ADT) Received: from perhan.alvh.no-ip.org (200-126-123-196.bk8-dsl.surnet.cl [200.126.123.196]) (authenticated bits=0) by lists.commandprompt.com (8.13.8/8.13.8) with ESMTP id m4E0oZNw008678 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 May 2008 17:50:38 -0700 Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id E6CF947C5C; Tue, 13 May 2008 20:49:33 -0400 (CLT) Date: Tue, 13 May 2008 20:49:33 -0400 From: Alvaro Herrera To: kevin kempter Cc: Tom Lane , Tino Schwarze , pgsql-admin@postgresql.org Subject: Re: Deadlocks ? Message-ID: <20080514004933.GR6966@alvh.no-ip.org> References: <8490DCB9-7D9B-47E5-B5A6-A0FD52C30C59@kevinkempterllc.com> <20080513193048.GA15701@easy2.in-chemnitz.de> <7586.1210719628@sss.pgh.pa.us> <506ECCFC-6568-4CD3-B4AF-25A860D97859@kevinkempterllc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <506ECCFC-6568-4CD3-B4AF-25A860D97859@kevinkempterllc.com> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (lists.commandprompt.com [207.173.203.159]); Tue, 13 May 2008 17:50:38 -0700 (PDT) X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200805/115 X-Sequence-Number: 29199 kevin kempter wrote: >>> On Tue, May 13, 2008 at 01:18:24PM -0600, kevin kempter wrote: >>> ProgrammingError: deadlock detected >>> DETAIL: Process 23098 waits for ShareUpdateExclusiveLock on >>> relation 428126 of database 427376; blocked by process 23916. >>> Process 23916 waits for ShareLock on transaction 46802680; blocked >>> by process 23098. > If that's true does it make sense to play with a timeout value (I assume > the timeout is configurable somewhere in postgresql.conf) in an effort to > tune for this ? If there's a deadlock, it's gonna wait until detected, so no matter how large you set the timeout, there's no getting out of it. If it were a plain lock wait, it would make sense to try to increase the timeout. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support