Re: BUG #6629: Creating a gist index fails with "too many LWLocks taken"
От | Tom Lane |
---|---|
Тема | Re: BUG #6629: Creating a gist index fails with "too many LWLocks taken" |
Дата | |
Msg-id | 9944.1336761168@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #6629: Creating a gist index fails with "too many LWLocks taken" (Simon Riggs <simon@2ndQuadrant.com>) |
Список | pgsql-bugs |
Simon Riggs <simon@2ndQuadrant.com> writes: > OK, I agree. I still think this is about solving a non-problem. > The implementation I would prefer would be to put the check in > START_CRIT_SECTION(); so we actually fail before we enter the section. ... and this is proposing adding significant overhead to solve a non-problem. The suggested warning can be added without any new cycles in the normal case, ie, where we currently have if (lockcount >= 100) elog(ERROR, ...); we can do something like if (lockcount >= 20) { if (lockcount >= 100) elog(ERROR, ...); else elog(WARNING, ...); } I think that's more than sufficient. We've had the LWLock mechanism for umpteen years now, and this hasn't come up before, and now that it has come up it was because of a locking usage that needed to be rewritten anyway. That is *not* good evidence for adding complexity and cycles to the mechanism to make it more failsoft. It shouldn't need to be failsoft. regards, tom lane
В списке pgsql-bugs по дате отправления: