Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id 305D11337C2E for ; Fri, 18 Mar 2011 15:18:53 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia, port 10024) with ESMTP id 89873-06-4 for ; Fri, 18 Mar 2011 18:18:44 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from midnight-anchovy.ambulatoryclam.net (unknown [18.141.0.210]) by mail.postgresql.org (Postfix) with ESMTP id B04C31337BE7 for ; Fri, 18 Mar 2011 15:18:32 -0300 (ADT) Received: by midnight-anchovy.ambulatoryclam.net (Postfix, from userid 1001) id 1AC354AC70; Fri, 18 Mar 2011 14:18:32 -0400 (EDT) Date: Fri, 18 Mar 2011 14:18:32 -0400 From: Dan Ports To: pgsql-hackers@postgresql.org Subject: Re: SSI bug? Message-ID: <20110318181832.GB72629@csail.mit.edu> References: <20110221234236.4635E19D574@mail.netbsd.org> <20110221234236.4635E19D574@mail.netbsd.org> <20110318022622.196E519CFCA@mail.netbsd.org> <4D835508020000250003BAD2@gw.wicourts.gov> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D835508020000250003BAD2@gw.wicourts.gov> User-Agent: Mutt/1.5.21 (2010-09-15) X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.107 tagged_above=-5 required=5 tests=BAYES_00=-1.9, RDNS_NONE=0.793 X-Spam-Level: X-Archive-Number: 201103/1159 X-Sequence-Number: 184409 It would probably also be worth monitoring the size of pg_locks to see how many predicate locks are being held. On Fri, Mar 18, 2011 at 12:50:16PM -0500, Kevin Grittner wrote: > Even with the above information it may be far from clear where > allocations are going past their maximum, since one HTAB could grab > more than its share and starve another which is staying below its > "maximum". I'll take a look at the possibility of adding a warning > or some such when an HTAB expands past its maximum size. Yes -- considering how few shared memory HTABs have sizes that are really dynamic, I'd be inclined to take a close look at SSI and max_predicate_locks_per_transaction regardless of where the failed allocation took place. But I am surprised to see that error message without SSI's hint about increasing max_predicate_locks_per_xact. Dan -- Dan R. K. Ports MIT CSAIL http://drkp.net/