Re: BUG #6629: Creating a gist index fails with "too many LWLocks taken"
От | Robert Haas |
---|---|
Тема | Re: BUG #6629: Creating a gist index fails with "too many LWLocks taken" |
Дата | |
Msg-id | CA+TgmoZzr+9JdT2Tus6RAMG+q87JupTFAw7TyMfZKpjTQO21qQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #6629: Creating a gist index fails with "too many LWLocks taken" (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-bugs |
On Fri, May 11, 2012 at 10:19 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes: >> On 11.05.2012 16:52, Tom Lane wrote: >>> IMO, no part of the system should ever get within an order of magnitude >>> of holding 100 LWLocks concurrently. > >> I agree we should never get anywhere near that limit. But if we do - >> because of another bug like this one - it would be nice if it was just >> an ERROR, instead of a PANIC. > > By the time you hit that limit, you have already got a problem that > should never have gotten into the field, I think. =A0Simon's idea of > logging a warning once we get beyond a sane number of LWLocks seems like > it might be helpful towards finding such problems earlier; though I'd > put the "sane" limit at maybe 20 or so. +1. > Perhaps it'd be useful to > measure what the max length of that list is during the regression tests. Yeah. And maybe any build with --enable-cassert should also emit WARNINGs when we go past whatever we determine the same limit to be. --=20 Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-bugs по дате отправления: