Re: SSI bug?

On Fri, Mar 25, 2011 at 4:06 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Fri, Mar 18, 2011 at 5:57 PM, Kevin Grittner
>> <Kevin(dot)Grittner(at)wicourts(dot)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".

What about a system view that shows declared & actual sizes of all
these hash tables?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company