To: Robert Haas <robertmhaas@gmail.com>
cc: Kevin Grittner <Kevin.Grittner@wicourts.gov>,
	Dan Ports <drkp@csail.mit.edu>, YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>,
	pgsql-hackers@postgresql.org
Subject: Re: SSI bug? 
In-reply-to: <AANLkTimgy7xgS0zdC0LiU=5zgsSGwKGTaPppeza7WAQb@mail.gmail.com> 
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>
	<AANLkTimgy7xgS0zdC0LiU=5zgsSGwKGTaPppeza7WAQb@mail.gmail.com>
Comments: In-reply-to Robert Haas <robertmhaas@gmail.com>
	message dated "Fri, 25 Mar 2011 15:18:41 -0400"
Date: Fri, 25 Mar 2011 16:06:30 -0400
Message-ID: <15645.1301083590@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Robert Haas <robertmhaas@gmail.com> writes:
> On Fri, Mar 18, 2011 at 5:57 PM, Kevin Grittner
> <Kevin.Grittner@wicourts.gov> wrote:
>>> I'm still looking at whether it's sane to try to issue a warning
>>> when an HTAB exceeds the number of entries declared as its
>>> max_size when it was created.

> I don't think it's too late to commit something like this, but I'm not
> clear on whether we want it.

We do *not* want that.

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...)

There might perhaps be some value in adding a warning like this if it
were enabled per-table (and not enabled by default).  But I'd want to
see a specific reason for it, not just "let's see if we can scare users
with a WARNING appearing out of nowhere".

			regards, tom lane