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 | 2941.1336744377@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #6629: Creating a gist index fails with "too many LWLocks taken" (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Ответы |
Re: BUG #6629: Creating a gist index fails with "too many
LWLocks taken"
|
Список | pgsql-bugs |
Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes: > I wonder if we should reserve a few of the lwlock "slots" for critical > sections, to make this less likely to happen. Not only in this case, but > in general. We haven't seen this problem often, but it would be quite > trivial to reserve a few slots. I'm against that: it would complicate a performance-critical and correctness-critical part of the code, in return for what exactly? IMO, no part of the system should ever get within an order of magnitude of holding 100 LWLocks concurrently. For one thing, I don't believe it's possible to statically guarantee no deadlock once things get that messy; and for another, it'd surely be horrible from a concurrency standpoint. So anytime we find something that's reaching that limit, the solution is to fix the lock usage, not to make the limit more forgiving. regards, tom lane
В списке pgsql-bugs по дате отправления: