Re: SSI bug? - Mailing list pgsql-hackers

From Robert Haas
Subject Re: SSI bug?
Date
Msg-id AANLkTik-m_3Q4T=D31DkVd-w8X8PzRSug9bvmWetNF3g@mail.gmail.com
Whole thread Raw
In response to Re: SSI bug?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, Mar 25, 2011 at 4:06 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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".

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


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Pre-set Hint bits/VACUUM FREEZE on data load..?
Next
From: Heikki Linnakangas
Date:
Subject: Re: Pre-set Hint bits/VACUUM FREEZE on data load..?