Re: SSI bug?
От | Robert Haas |
---|---|
Тема | Re: SSI bug? |
Дата | |
Msg-id | AANLkTik-m_3Q4T=D31DkVd-w8X8PzRSug9bvmWetNF3g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: SSI bug? (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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 по дате отправления: