On Fri, Mar 25, 2011 at 4:06 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Fri, Mar 18, 2011 at 5:57 PM, Kevin Grittner >> <kevin.gritt...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
