Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id F0E01133740B for ; Sat, 26 Mar 2011 18:55:06 -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 39733-07 for ; Sat, 26 Mar 2011 21:54:58 +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 5963F133616B for ; Sat, 26 Mar 2011 18:54:58 -0300 (ADT) Received: by midnight-anchovy.ambulatoryclam.net (Postfix, from userid 1001) id C44304AC2C; Sat, 26 Mar 2011 17:54:52 -0400 (EDT) Date: Sat, 26 Mar 2011 17:54:52 -0400 From: Dan Ports To: Tom Lane Cc: Robert Haas , Kevin Grittner , YAMAMOTO Takashi , pgsql-hackers@postgresql.org Subject: Re: SSI bug? Message-ID: <20110326215452.GA72629@csail.mit.edu> References: <20110221234236.4635E19D574@mail.netbsd.org> <20110318022622.196E519CFCA@mail.netbsd.org> <4D835508020000250003BAD2@gw.wicourts.gov> <20110318181832.GB72629@csail.mit.edu> <4D837F6F020000250003BAF6@gw.wicourts.gov> <4D838EFC020000250003BB12@gw.wicourts.gov> <15645.1301083590@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15645.1301083590@sss.pgh.pa.us> 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/1559 X-Sequence-Number: 184809 On Fri, Mar 25, 2011 at 04:06:30PM -0400, Tom Lane wrote: > Up to now, I believe the lockmgr's lock table is the only shared hash > table that is expected to grow past the declared size; that can happen > anytime a session exceeds max_locks_per_transaction, which we consider > to be only a soft limit. I don't know whether SSI has introduced any > other hash tables that behave similarly. (If it has, we might want to > rethink the amount of "slop" space we leave in shmem...) I looked into this recently and the two lockmgr tables were indeed the only ones that could vary in size. IIRC, the only other shared hash tables were the shared buffer index and the shmem index. SSI adds two more analogous tables (per-lock-target and per-xact-lock), both of which are sized according to max_pred_locks_per_transaction, which is also a soft limit. It also adds a per-transaction shared hash table, but that has a clear maximum size. I find the soft limit on htab size a strange model, and I suspect it might be a source of problems now that we've got more than one table that can actually exceed it its limit. (Particularly so given that once shmem gets allocated to one htab, there's no getting it back.) Dan -- Dan R. K. Ports MIT CSAIL http://drkp.net/