Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id 48D801337990 for ; Thu, 31 Mar 2011 12:50:47 -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 72737-06 for ; Thu, 31 Mar 2011 15:50:29 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by mail.postgresql.org (Postfix) with ESMTP id BB9051337B93 for ; Thu, 31 Mar 2011 12:50:28 -0300 (ADT) Received: from source ([209.85.215.171]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKTZSiwIRq/0FBYpITeDiylJRBLbA37j5B@postini.com; Thu, 31 Mar 2011 08:50:29 PDT Received: by eydd26 with SMTP id d26so1199183eyd.30 for ; Thu, 31 Mar 2011 08:50:23 -0700 (PDT) Received: by 10.14.16.100 with SMTP id g76mr1505930eeg.168.1301586623143; Thu, 31 Mar 2011 08:50:23 -0700 (PDT) Received: from [192.168.1.183] (dsl-hkibrasgw2-ff7ac300-240.dhcp.inet.fi [88.195.122.240]) by mx.google.com with ESMTPS id b52sm802153eei.22.2011.03.31.08.50.21 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 31 Mar 2011 08:50:22 -0700 (PDT) Message-ID: <4D94A2BB.3090605@enterprisedb.com> Date: Thu, 31 Mar 2011 18:50:19 +0300 From: Heikki Linnakangas User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; fi-FI; rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11 MIME-Version: 1.0 To: Kevin Grittner CC: YAMAMOTO Takashi , drkp@csail.mit.edu, pgsql-hackers@postgresql.org Subject: Re: SSI bug? References: <4D8F54E6020000250003BD16@gw.wicourts.gov>Your message of "Sun, 27 Mar 2011 15:16:54 -0500" <4D8F54E6020000250003BD16@gw.wicourts.gov> <20110328031616.CDAA719CEDF@mail.netbsd.org> <4D943BEC020000250003BFDA@gw.wicourts.gov> In-Reply-To: <4D943BEC020000250003BFDA@gw.wicourts.gov> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.9 tagged_above=-5 required=5 tests=BAYES_00=-1.9 X-Spam-Level: X-Archive-Number: 201103/1891 X-Sequence-Number: 185141 On 31.03.2011 16:31, Kevin Grittner wrote: > I've stared at the code for hours and have only come up with one > race condition which can cause this, although the window is so small > it's hard to believe that you would get this volume of orphaned > locks. I'll keep looking, but if you could try this to see if it > has a material impact, that would be great. > > I am very sure this patch is needed and that it is safe. It moves a > LWLockAcquire statement up to cover the setup for the loop that it > already covers. It also includes a fix to a comment that got missed > when we switched from the pointer between lock targets to > duplicating the locks. Ok, committed. Did we get anywhere with the sizing of the various shared memory structures? Did we find the cause of the "out of shared memory" warnings? Would it help if we just pre-allocated all the shared memory hash tables and didn't allow them to grow? It's bizarre that the hash table that requests the slack shared memory space first gets it, and it can't be reused for anything else without a server restart. I feel it would make better to not allow the tables to grow, so that you get consistent behavior across restarts. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com